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Executive  Summary 

This  document  is  the  final  report  of  a  project  to  review  the  process  followed  by  the  Directorate  of 
Land  Requirements  (DLR)  to  develop  a  Statement  of  Operational  Requirement  (SOR),  and  to 
generate  the  requirements  for  a  software  tool  to  support  the  SOR  development  process. 

The  analysis  of  the  requirements  management  process  within  DLR  identified  a  number  of 
deficiencies  in  the  current  system.  These  deficient  areas  included: 

•  DLR  and  Army  Culture 

•  Lack  of  Scenarios,  Doctrine,  and  Operational  Concepts 

•  Access  to  Information  and  Resources 

•  SOR  Development  Process 

•  SOR  Format 

•  Integration  of  Human  Factors  in  the  SOR 

•  The  Link  with  ADM(Mat) 

•  Requirements  Traceability 

Each  group  of  deficiency  has  generated  a  series  of  requirements  for  change  in  the  SOR 
Development  Process,  proposed  modifications  to  the  SOR  Format  Template,  and  identified 
requirements  to  guide  the  procurement  or  development  of  SOR-Spec  Maker  (a  requirements 
management  tool). 

This  report  is  considered  the  first  step  in  the  SOR-Spec  Maker  project,  with  required  future  stages 
consisting  of: 

•  Liaison  with  parallel  projects  developing  new  SOR  formats  for  the  Canadian  Forces 
(through  the  Directorate  of  Force  Planning  and  Project  Coordination)  to  integrate  the 
results  of  this  study  and  ensure  that  the  human  factors  aspects  of  the  SOR  Template  are 
considered  in  force  wide  initiatives. 

•  Review  of  additional  requirements  management  tools,  resulting  in  the  selection  of  one  tool 
to  be  used  in  an  example  project.  This  example  project  should  be  used  as  the  basis  for 
user  reviews,  a  part  task  user  trial,  and  the  development  of  a  final  set  of  SOR-Spec  Maker 
Requirements  to  guide  procurement. 
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1  Introduction 


This  document  is  the  final  report  of  a  project  to  review  the  process  followed  by  the  Directorate  of 
Land  Requirements  (DLR)  to  develop  a  Statement  of  Operational  Requirement  (SOR),  and  to 
generate  the  requirements  for  a  software  tool  to  support  the  SOR  development  process.  The 
project  has  been  completed  by  Humansystems  Incorporated  (HSI)  under  contract  to  the  Defence 
and  Civil  Institute  of  Environment  Medicine  (DCIEM)  under  PWGSC  Contract  No.W771 1-6- 
7286/00 1-SRV. 

1.1  Background 

DCIEM  has  been  considering  the  development  of  a  requirements  tool  that  will  facilitate  the 
integration  of  human  factors  provisions  into  system  requirements.  In  parallel  to  this  initiative,  the 
Directorate  of  Land  Requirements  (DLR)  has  been  investigating  management  tools  to  assist  in  the 
development,  tracking,  maintenance,  and  testing  of  system  requirements  on  a  large  scale.  As  a 
result  of  this  shared  interest,  DLR  invited  DCIEM  to  participate  in  an  investigation  of  the  SOR 
development  process  through  the  Defence  Research  and  Development  Branch  (DRDB). 

DCIEM  chose  to  contract  this  analysis  activity  to  Yiumansystems  Incorporated.  Humansy.ste/w.s 
had  prior  experience  conducting  this  type  of  analysis  on  other  DND  software  projects,  in  addition 
to  extensive  human  factors  experience  on  military  acquisition  projects. 

1.2  Objective 

The  objectives  of  the  project  were  to: 

•  Assist  DLR  and  DCIEM  in  the  identification  of  their  needs  for  a  requirements  software 
management  tool, 

•  Develop  a  clear  understanding  of  the  SOR  development  process  and  identify  any 
recommended  improvements  to  this  process, 

•  Document  the  methods  used  to  check  and  revise  requirements  during  system  development, 

•  Develop  an  SOR  Requirements  Template,  including  a  human  factors  requirements 
package  embedded  in  the  template,  and 

•  Determine  the  feasibility  of  incorporating  a  requirements  management  product  as  a 
module  within,  or  linking  it  to.  Soldiers  Day  and/or  HFE  Guide,  either  as  stand  alone 
software  or  a  world-wide-web  site. 
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1.3  Scope 

The  analysis  conducted  under  this  project  was  limited  in  resources,  which  limited  the  scope  in  a 

number  of  ways: 

•  The  analysis  was  “  wide”  and  not  “deep” ,  focusing  on  a  broad  understanding  of  the  SOR 
and  Performance  Specification  development  process. 

•  The  resulting  SOR-Spec  Maker  requirements  are  therefore  high  level,  task  related, 
requirements  and  should  undergo  more  detailed  development  prior  to  being  used  as  the 
complete  basis  for  software  procurement. 

•  A  number  of  Land  Forces  projects  were  analyzed  which  were  expected  to  provide  a 
representative  cross  section  of  SORs.  However,  further  projects  should  be  reviewed 
against  the  results  of  this  study  to  validate  the  results  prior  to  changing  the  development 
process  or  finalizing  software  requirements. 

•  The  Human  Factors  “  package”  of  the  SOR  template  was  limited  to  the  SOR  sub-sections 
that  should  be  added  to  properly  integrate  human  factors,  with  some  guidance  on  their 
expected  contents. 

1.4  Deliverables 

A  number  of  deliverables  were  required  from  this  project  including: 

•  Documentation  of  the  SOR  development  process,  including  flow  charts  of  information 
flow  and  task  sequences. 

•  An  SOR  Template  with  an  embedded  Human  Factors  Package. 

•  A  Final  Report  integrating  the  Method,  Results,  and  Recommendations  from  the  analysis 
and  the  above  two  deliverables. 

•  A  Presentation  of  the  Final  Report  in  Ottawa. 
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2  Method 


In  order  to  analyze  the  SOR  development  process  and  derive  the  requirements  for  a  management 
tool  a  series  of  analyses  were  conducted,  including: 

•  The  analysis  of  a  number  of  project  scenarios  to  understand  the  process  in  terms  of  how 
SORs  are  initiated,  created,  validated,  edited,  turned  into  Performance  Specifications, 
tracked  during  development,  and  tested. 

•  The  analysis  of  key  tasks  in  the  SOR  Development  Process  in  terms  of  key  information 
sources,  major  challenges  or  sources  of  error,  the  types  of  requirements,  the  lessons  learned 
on  past  projects,  and  the  identification  of  areas  where  management  software  could  provide 
assistance. 

•  The  identification  of  areas  where  improvements  could  be  made  to  the  SOR  Development 
Process. 

•  The  derivation  of  SOR-Spec  Maker  software  requirements  from  this  analysis. 

These  analyses  were  completed  using  three  primary  methods  of  data  collection: 

•  Interviews 

•  SOR  Reviews 

•  Software  Product  Reviews 

2.1  Interviews 

At  the  project  start  up  meetings  with  DLR,  DCIEM,  and  DRDB  discussions  were  held  to 
determine  who  should  be  consulted  in  the  analysis  process.  A  number  of  sources  were  identified 
through  these  discussions,  with  five  groups  of  personnel  selected  as  important  information 
sources: 

1 .  The  Technical  Staff  Course  in  Kingston 

This  group  was  selected  to  provide  an  understanding  of  the  background  on  SOR 
development  that  Requirements  Officers  obtain  at  the  Tech  Staff  School  prior  to  joining  a 
DLR  project  office. 

2.  DLR  Coordination  Staff 

This  group  was  selected  to  provide  an  overview  of  the  overall  process. 

3 .  DLR  Project  Case  Studies 

These  projects  were  selected  for  more  detailed  study  to  provide  insights  on  the  range  of 
methods  used  to  develop  SORs  and  the  challenges  that  Requirements  Officers  must 
overcome. 

4.  DLERM  and  other  Project  Management  Staff 

These  personnel  were  selected  to  provide  insights  into  the  engineering  side  of  the  process, 
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and  the  development  of  the  Performance  Specifications  used  for  procurement  and 
development. 

5.  DCIEM  Scientific  Authorities 

These  personnel  were  selected  to  provide  insights  into  the  integration  of  human  factors  in 
the  requirements  development  process. 

As  a  result  of  startup  meeting  discussions  it  was  determined  that  DLR  projects  could  be  loosely 
classified  into  three  groups,  regardless  of  which  DLR  section  they  were  initiated  from.  Within 
these  groups  a  number  of  projects  were  identified  for  analysis  with  the  understanding  that  not  all 
could  be  fully  investigated  within  the  scope  of  the  current  project.  The  three  groups,  and  the 
projects  that  were  actually  analyzed  included: 

1.  C3I/C4I 

aj  Land  Force  Command  System  (LFCS) 
b)  Tactical  Battlefield  Command  System  (TBCS) 

2.  Major  Equipment  and  Vehicles 

a)  Armoured  Combat  Vehicle  (ACV) 

b)  Armoured  Personnel  Carrier  Life  Extention  (APC  LE)  (SOR  Review  Only) 

3.  Soldier  Centric  Items 

a)  Integrated  Protective  Clothing  and  Equipment  (IPCE) 

b)  Helmet  and  Soldier’s  Helmet  Accessories 

c)  Clothe  the  Soldier,  including: 

•  Cold  Wet  Weather  Glove 

•  Improved  Environmental  Clothing  System 

’ '  •  Combat  Sock 

Note:  It  is  important  to  note  that  the  Humansystems  project  team  also  had 
insights  into  the  requirements  development  and  management  process  on  a 
number  of  other  projects.  This  insight  was  developed  through  contracts 
completed  during  the  preceding  10  years.  These  projects  included  a  wide  range 
of  clothing  and  equipment  contracts,  the  105mm  Howitzer  projects,  the  Artillery 
Regimental  Data  System  (ARDS)  project,  and  the  Advanced  Land  Fire  Control 
System  (ALFCS)  and  Defensive  Aids  Suite  (DAS)  projects. 

A  rough  interview  protocol  was  developed  to  guide  the  interviews  with  DLR  and  Kingston 
Technical  School  Staff  about  the  requirements  development  and  management  process.  The  key 
elements  of  these  interviews  included: 

1 .  Introductions  and  a  Discussion  of  the  Purpose  of  the  Interview 

2.  Questions  on  the  History  of  the  Project 

•  Why  was  the  project  started,  and  what  was  the  project  goal? 

•  What  is  the  current  SOR  structure  and  content? 
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•  What  was  the  process  or  major  steps  in  the  development  of  the  SOR? 

•  How  did  the  DLR  staff  determine  the  requirements  ? 

•  What  were  the  key  information  inputs  and  sources  ? 

•  How  were  the  requirements  validated,  with  users  and  with  others? 

•  Were  there  any  human  performance  related  requirements  developed? 

•  What  were  the  major  problems,  challenges,  and  lessons  learned  during  the 
development  of  the  SOR  and  management  of  requirements  throughout  the  project  life 
cycle? 

3 .  Transition  of  the  SOR  to  the  Specification  and  the  RFP/SOW 

•  How  do  requirements  transition  to  specifications? 

•  What  are  the  key  data  to  transfer  from  the  SOR  to  the  Spec? 

•  What  are  the  major  problems  or  challenges  in  the  transition  of  requirements  to 
specifications? 

4.  Tracking  Through  Product/System  Development  or  Implementation 

•  How  are  requirements  tracked  through  the  implementation  phase? 

•  How  are  the  requirements  revised  (if  necessary)? 

•  How  is  the  history  of  decision  making  tracked? 

•  How  are  requirements  tested  through  development? 

•  Where  do  testing  criteria  come  from? 

•  How  is  testing  tracked? 

In  addition  to  these  process  related  interviews,  D.C.I.E.M.  human  factors  personnel  were 
interviewed  for  input  on  the  integration  of  human  factors  engineering  in  systems  design.  Key 
issues  in  these  interviewees  included: 

1 .  What  are  DCIEM  staff  expectations  for  the  integration  of  Human  Factors  in  Statements  of 
Operational  requirements? 

2.  What  are  the  range  of  human  factors  requirements  that  should  be  integrated  in  an  SOR? 

3 .  What  are  the  human  factors  lessons  from  past  projects  where  human  factors  requirements 
have  not  been  adequately  addressed  or  integrated? 

4.  What  are  the  lessons  learned  from  the  integration  of  human  factors  in  other  elements  of 
the  Canadian  forces  (Air/Navy/Service)? 
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2.2  SOR  Reviews 

The  SORs  for  the  listed  projects  were  all  reviewed  for: 

1.  Structure  and  Boiler  Plate 

2.  Types  of  Requirements 

3 .  Volume  of  Requirements 

4.  Differences  Between  Project  Types 

5.  Links  to  Other  Documents  or  References 

6.  Integration  of  Human  Factors  Issues 

2.3  Software  Product  Reviews 

Two  types  of  software  products  were  reviewed  during  the  project,  including: 

1 .  Requirements  Management  Tools. 

These  tools  included  ReqMan  and  RT  Expert,  both  of  which  are  requirements 
management  tools  that  are  candidates  for  the  SOR-Spec  Maker  product.  These  products 
were  reviewed  to  determine  if  they  generally  meet  the  requirement  for  software  based 
requirements  management  support. 

2.  Human  Factors  Tools. 

These  tools  included  Soldier’s  Day  and  HFE  Guide.  Soldier’s  Day  is  a  database  tool  with 
information  on  the  missions/tasks/equipment  of  the  infantry.  HFE  Guide  is  a  hypertext 
based  tool  containing  military  human  factors  standards  and  guidance  on  task  analysis  and 
testing.  These  products  were  reviewed  to  determine  if  there  is  any  role  for  them  in  a 
software  suite  to  support  the  requirements  development  process. 
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3  Results 


This  section  outlines  the  results  of  the  analysis  described  in  Section  2.0.  The  section  contains  two 
categories  of  information  including: 

1 .  A  review  of  the  requirements  management  process  and  the  integration  of  human  factors 
within  this  process. 

2.  Identification  of  the  deficiencies  in  the  current  process  and  the  requirements  to  address 
these  deficiencies.  The  requirements  to  address  each  deficiency  area  are  grouped  into 
three  categories: 

•  Requirements  for  Changes  in  the  SOR  and  Performance  Spec  Development  Process, 

•  Requirements  for  Changes  to  the  SOR  Document  Format,  and 

•  Requirements  for  an  SOR-Spec  Maker  Software  Tool. 

A  summary  of  primary  project  recommendations,  with  comments  on  the  “way-ahead”  for  the 
SOR-Spec  Maker  project,  is  provided  in  Section  4.0  of  this  report. 

3.1  Analysis  of  the  Requirements  Management  Process 

3.1.1  The  Directorate  of  Land  Requirements 

The  Canadian  Forces  are  functionally  grouped  into  a  number  of  elements  that  include  the  Army 
(Land  Force),  Navy,  and  Air  elements.  Each  of  these  elements  have  headquarters  directorates 
responsible  for  the  specification  and  delivery  of  systems  and  equipment  to  support  operations.  In 
the  Land  Force  element  this  group  is  called  the  Directorate  of  Land  Requirements  (DLR). 

DLR  exists  to  translate  army  needs  into  systems  and  equipment  to  support  those  needs.  The  major 
functions  that  DLR  performs  in  support  of  this  aim  include: 

•  Monitoring  of  Technological  Developments  (both  friendly  and  threat  forces) 

•  Definition  of  Requirements  and  Projects 

•  Negotiation  for  Project  Resources 

To  complete  these  tasks  for  the  Land  Forces,  personnel  are  organized  into  functional  teams 
according  to  the  type  of  system  or  equipment  that  needs  to  be  procured  at  any  one  time.  During 
the  analysis  for  this  project  DLR  was  organized  within  three  groups  (see  Figure  1): 

1.  Program  Co-ordination. 

This  group  of  personnel  is  responsible  for  DLR  issues  common  to  the  development  of  all 
systems  and  products,  such  as  interfaces  with  other  agencies,  research  and  development, 
testing  and  evaluation,  or  the  development  of  training  and  simulation. 

2.  Matrix  Sections. 

This  group  of  personnel  support  what  are  known  as  “  matrix  positions” .  These  staff 
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generally  deal  with  the  monitoring  of  science  and  technology,  and  with  projects  either 
very  early  or  very  late  in  their  life  cycles.  Also  included  in  these  sections  are  personnel 
who  are  assigned  to  smaller  sized  projects  where  the  project  team  is  composed  of 
personnel  who  may  work  on  other  projects  at  the  same  time.. 

3 .  Project  Management  Offices. 

This  group  of  personnel  are  the  DLR  staff  assigned  to  large  Project  Management  Offices 
(PMOsj  as  the  requirements  and  directing  staff.  These  assignments  occur  on  very  large 
projects  where  the  magnitude  of  the  project  requires  the  full  time  attention  of  one  or  more 
individuals  from  a  DLR  branch. 


•  26  Permanent  Positions, 
Varying  #  of  Project  Positions 


•  DLR  2:  Field  &  Air  Defence  Artillery, 

Survey  &  Target  Acquisition 

•  DLR  3:  Armour  Systems 

•  DLR  4:  Command  Information  Systems, 

Intelligence 

•  DLR  5:  Soldier  Systems 

(i)  Clothing/Equipment/Field  Craft, 

(ii)  Infantry  Weapons 

•  DLR  6:  Combat  Service  Support 

•  DLR  7:  Field  Engineering 

•  DLR  8:  Training  &  Simulation  (discontinued....) 


V 


•  Assignments  to  Large  Projects 

•  DLR  9:  Land  Reserve 

Modernization  Project 

•  DLR  10:  Light  Armoured  Vehicle 

Coyote  &  LAV  3  (APC 

Repl.) 

•  DLR  12:  TCCCS 

•  DLR  15:  TACOMS  2000+ 

Liason  in  Europe 


Figure  1:  The  General  Structure  of  DLR 
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3.1 .2  The  Creation  of  a  Project 

A  “  project”  within  DLR  can  be  initiated  in  a  number  of  ways,  but  the  initiation  generally  falls  into 
one  of  three  categories: 

1 .  The  army  comes  to  DLR  with  a  requirement. 

2.  DLR  identifies  a  requirement  by  monitoring  defence  and  industry  literature. 

3 .  The  defence  research  and  development  branch  (DRDB)  identifies  a  potential  requirement 
and  seeks  sponsorship  from  a  DLR  branch. 

The  Army  can  initiate  a  project  for  a  number  of  different  reasons,  with  common  ones  including: 

•  A  deficiency  based  on  recent  field  or  training  experience, 

•  A  unit  commander  identifying  a  product  that  will  enhance  operational  effectiveness 
through  trade  magazines  or  brochures, 

•  A  directed  purchase  based  on  the  political  process,  whereby  there  are  some  additional 
benefits  to  the  good  of  the  country  as  well  as  the  operation  of  the  military. 

As  a  result  of  this  wide  range  of  project  influences  the  Requirements  Officer  must  be  able  to 
develop  and  manage  a  set  of  requirements  under  a  range  of  very  dynamic  conditions. 

3.1.3  The  Requirements  Officer  and  the  Project  Team 

The  DLR  contribution  to  a  project  team  will  most  often  consist  of  a  Project  Director  at  the  least.  If 
it  is  a  small  project  the  Project  Director  will  also  be  the  Requirements  Officer,  with  larger  projects 
having  both  a  PD  and  a  number  of  additional  staff  roles  in  support,  one  of  which  is  likely  to  be  the 
Requirements  Officer  for  the  project.  For  the  remainder  of  this  report  the  terms  Project  Director 
or  Requirements  Officer  will  be  used  interchangeably  to  describe  the  role  of  the  DLR  personnel 
responsible  for  the  development  and  management  of  project  requirements. 

The  Requirements  Officer  will  be  posted  into  their  position  from  their  units  as  per  the  normal 
career  management  and  posting  process.  The  typical  posting  to  DLR  is  2  to  6  years,  with  projects 
lasting  from  periods  of  months  to  decades. 

There  are  no  formal  job  requirements  for  a  DLR  staff  member,  however  there  are  some  desired 
qualifications  for  personnel  being  posted  to  Requirements  Officer  positions,  such  as: 

•  Recent  operational  experience 

•  Experience  in  the  Combat  Arms  (Armour,  Artillery,  Infantry,  Engineers) 

•  The  rank  of  middle/senior  Captain  or  Major 

•  Graduation  from  a  Technical  Staff  Course  in  Shrivenham  or  Kingston  (most  have  this) 
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The  basic  elements  of  a  project  team  will  include  both  Project  Directing  staff  (from  DLR)  and 
Project  Management  staff  from  the  engineering  community  who  work  under  the  Assistant  Deputy 
Minister  (Material)  (ADM(Mat)). 

3.1.4  Key  Milestones  of  a  Project 

There  are  some  key  milestones  of  a  project  that  relate  to  the  development  of  requirements  and 
specifications  (see  Figure  2).  These  milestones  relate  to  Synopsis  Sheets  (SS)  required  by  the 
Treasury  Board  to  approve  project  funding.  The  three  key  milestones  include: 

1.  Identification  -  SS(ID) 

This  is  the  first  presentation  of  a  project,  with  the  SS  including: 

•  The  Definition  of  the  Project,  with  a  Rough  Estimate  of  Project  Cost 

•  A  Detailed  Estimate  of  Project  Development  (Pre-Definition)  Costs 

•  If  Approved,  the  Requirement  Officer  moves  into  the  development  phase  and  starts  to 
evaluate  different  options  to  meet  the  project  needs  and  initiate  SOR  development. 

2.  Preliminary  Project  Approval  -  SS(PPA) 

This  SS  goes  to  the  Treasury  Board  for  Analysis  and  Review  and  includes: 

•  Project  Proposal  and  Risk  Analysis  (PPRA) 

•  A  Better  Estimate  of  Project  Cost  for  Major  Option  Selected  for  the  Project 

•  A  Substantive  Cost  for  Project  Definition 

•  If  Approved,  the  project  has  approval  in  principle  and  spending  approval  for  the 
Project  Definition  Phase  which  will  include  the  completion  of  a  Statement  of 
Operational  Requirement  (SOR). 

3.  Effective  Project  Approval  -  SS(EPA) 

At  this  point  the  Requirement  Officer  returns  to  Treasury  Board  for  Review  of: 

•  The  Statement  of  Operational  Requirement 

•  The  Substantive  Project  Cost  Estimates 

•  If  Approved,  the  project  has  expenditure  authority  for  Implementation  phase  which 
will  include  receiving  bids  and  procurement/development  of  the  system.  This 
expenditure  approval  may  have  gates  associated  with  it  whereby  further  funding  will 
not  be  released  until  a  milestone  has  been  met  (this  is  increasingly  common  on 
software  projects). 
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Requirement 

Analysis/Concept 


Project  Development 
Pre-Definition 

•  Options  Analysis 

•  Risk  Analysis 

•  Cost  Estimates  — 

•  Project  Proposal 


Project  Definition  <■ 

•  Detailed  Costing 

•  SOR  Development  — 


Project  Implementation  < - 

•  Development  and/or 
Procurement 

Figure  2:  Project  Milestones 

3.1 .5  The  Statement  of  Operational  Requirement 

The  Statement  of  Operational  Requirement  (SOR)  for  a  project  is  the  statement  of  the  “users 
need”  to  meet  a  deficiency  in  the  current  operational  capability  of  the  Land  Forces.  As  such,  it 
contains  the  functional  description  of  the  requirements  (“  What”  the  system  needs  to  do)  and  not  a 
technical  description  of  a  system  (“How”  a  system  should  be  built).  The  final  SOR  document 
should  not  be  linked  to  any  particular  product,  but  should  outline: 

•  What  the  Product  or  System  Needs  to  Do 

•  Key  Features  the  Product  Must  Have  to  Support  Task  Performance 

•  Conditions  Under  Which  the  System  Must  Perform 


Within  the  SOR,  the  requirements  are  prioritized  as  Essential  or  Desirable  to  provide  some  form  of 
priority  that  can  be  used  to  guide  procurement  decisions. 

Once  completed,  the  SOR  is  used  by  the  Requirements  Officer  as  a  tool  to  negotiate  with  Project 
Management  staff  as  the  basis  of  future  performance  and  technical  specifications. 

3.1.6  The  SOR  Development  Process 

The  SOR  is  initiated  at  any  time,  from  prior  to  SS(ID)  right  up  to  the  last  minute  prior  to  SS(EPA). 
The  SOR  is  usually  completed  Prior  to  SS(EPA)  but  at  the  moment  it  is  not  absolutely  required 
prior  to  moving  on  to  project  implementation.  In  most  cases  the  SOR  is  initiated  during  Pre- 
Definition  (Prior  to  SS(PPA))  and  then  “  Tuned”  during  the  Definition  Phase  (Prior  to  SS(EPA)). 

The  development  of  the  SOR  is  usually  the  responsibility  of  one  person  within  the  DLR  project 
team.  At  a  minimum  this  Requirements  Officer  will: 

•  Search  for  All  Available  Information  Sources 

•  Search  for  Previous  or  Similar  SORs 
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•  Develop  the  SOR  to  the  Best  of  Ones  Ability 

•  Distribute  the  SOR  for  Comment  to: 

•  the  local  DLR  branch  and  then  within  the  remainder  of  DLR, 

•  the  PM  Engineering  Staff, 

•  the  Units  across  Canada, 

•  Scientists  at  the  Defence  Research  Establishments  (DREs), 

•  the  Combat  Arm  Schools,  and  the  Technical  Staff  Course  in  Kingston, 

•  other  DND  Directorates  (Army  Doctrine,  Future  Concepts,  etc. . 

•  Edit  and  Finalize  The  SOR  Document 

This  general  process  is  as  official  as  the  process  ever  appears  to  get,  as  there  is  no  known 
documented  “  SOR  Development  Process”  within  DLR. 

Figure  3  attempts  to  illustrate  this  loose  process,  suggesting  that  a  number  of  information  inputs 
may  be  referenced  in  the  development  of  an  SOR,  after  which  the  requirements  go  through  some 
form  of  iterative  validation  process,  resulting  in  a  final  set  of  requirements  that  are  used  as  the 
basis  for  a  performance  specification. 


^  Figure  3:  Overview  of  SOR  Development 

As  illustrated  in  Figure  3,  a  wide  range  of  inputs  can  be  sought  in  the  development  of  a  set  of 
requirements  including: 


•  Previous  SORs 

•  Related  SORs 

•  SOR  Format  Templates 

•  Missions,  Scenarios,  and  Tasks 
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•  Standards 

•  Technical  Characteristics  of  Available  Equipment  from  Industry 

•  Research  Data,  from  Defence  and  Industrial  Sources 

Which  of  these  references  are  actually  used  is  highly  variable  between  projects,  and  is  based  on  a 
number  of  factors  including  the  Requirements  Officer  knowledge  of  resource  locations,  time,  and 
funding. 

The  iterative  requirement  validation  process  is  also  highly  variable  across  the  projects  within 
DLR.  This  range  of  validation  can  best  be  illustrated  through  a  description  of  the  two  extremes  of 
the  spectrum  (see  Figure  4). 

•  On  one  extreme  is  the  Document  Review  technique  of  requirements  validation.  In  this 
case  the  Requirements  Officer  develops  the  SOR  and  distributes  it  for  comment  to  a  range 
of  DND  personnel.  Usually  the  first  circulation  is  among  the  location  branch  of  DLR,  and 
then  all  of  DLR,  and  then  to  the  Units,  Schools,  and  Research  Establishments.  The  Army 
Doctrine  and  Future  Concepts  groups  are  also  likely  to  be  included  in  later  circulation  of 
the  document. 

•  On  the  other  extreme  is  the  Develop,  Test,  and  Iterate  technique  of  user  centered 
requirements  validation.  In  this  case  the  SOR  document  will  undergo  the  same  review  and 
comment  process  as  above,  but  the  requirements  will  be  validated  with  the  actual  future 
users  of  the  system  through  trials  at  the  units.  These  trials  will  range  from  Focus  Group 
discussions  using  illustrations  of  concepts  early  in  the  requirements  analysis  process,  to 
task  based  performance  trials  of  mockups,  prototypes,  or  buy-and-try  products.  These 
user  groups  are  often  conducted  by  human  factors  personnel  through  D.C.I.E.M.. 


Figure  4:  Range  of  Methods  for  SOR  Review  and  Validation 


Humansystews  Incorporated 


SOR-Spec  Maker  Final  Report 


Page  13 


3.1.7  SOR  Format 

Interviews  with  project  personnel  and  the  review  of  a  number  of  SORs  indicate  that  there  is  not 
one  consistent  format  for  SORs.  Interviews  determined  that  it  is  generally  believed  that  there  is  no 
SOR  format  template  to  follow.  In  addition,  it  is  taught  in  the  Kingston  Technical  Staff  Course 
that  there  is  no  formal  SOR  format  and  that  future  DLR  officers  will  be  required  to  develop  their 
own  format  to  suit  their  needs. 

However,  there  are  two  major  versions  in  existence  that  tend  to  reproduce  themselves  as  new 
projects  copy  the  format  used  in  older  projects.  These  two  major  types  of  SOR  format  include: 

•  The  Armoured/Vehicles  Version,  which  is  based  on  a  “  landscape”  oriented  document  that 
outlines  the  requirements  for  the  equipment  in  key  functional  areas  with  an  associated 
rationale  or  source  reference  beside  each  requirement  set. 

•  The  ‘Template’  Version,  which  is  most  similar  to  draft  SOR  templates  that  exist 
throughout  the  system.  This  format  is  based  on  a  “  portrait”  oriented  document  that 
contains  some  description  of  the  future  missions  and  tasks  for  the  system,  but  does  not 
include  rationale  as  part  of  the  document  itself. 

3.1.8  The  Performance  Specification 

Once  an  SOR  is  completed  and  approved,  most  projects  pass  through  SS(EPA)  and  become  fully 
funded  development  or  procurement  initiatives.  At  this  time  the  overall  responsibility  for  a  project 
shifts  from  the  Project  Director  in  DLR  to  the  Project  Manager  on  the  engineering  side 
(ADM(Mat)).  Once  this  transition  occurs  the  Requirements  officer  will  remain  responsible  for  the 
SOR  and  the  representation  of  user  interests  but  the  PM  staff  are  responsible  for  the  direction  of 
the  project.  The  key  document  produced  at  the  start  of  this  phase  of  the  project  is  the  Performance 
Specification  or  “  Spec” . 

To  develop  a  Spec,  the  engineering  staff  use  the  SOR  as  the  functional  basis  for  a  new  product  or 
system  and  endeavor  to  decompose  a  requirement  into  the  technical  and  performance 
specifications  that  must  be  met  to  achieve  the  requirement.  For  example  a  requirement  developed 
by  DLR  which  stated  a  glove  must  be  “waterproof  and  breathable”  might  turn  into  ten  pages  of 
specifications  related  to  what  the  Land  Forces  require  in  a  “  waterproof  and  breathable”  glove. 

During  the  development  of  the  Spec  the  engineering  staff  will  follow  a  similar  process  to  the  one 
followed  by  the  Requirements  Officer  in  the  development  of  the  SOR.  The  engineers  will  consult 
a  range  of  references  and  standards,  in  addition  to  literature  from  a  number  of  research  data 
sources.  Prototype  products  may  be  obtained  and  tested  as  well,  to  determine  if  specifications  are 
achievable  and  to  validate  specification  testing  techniques. 

In  the  development  of  the  Spec  the  engineers  will  attempt  to  determine  if  each  of  the  requirements 
can  be  achieved  based  on  industry  capability,  the  state  of  current  technology,  and  financial 
resources.  When  it  is  concluded  that  a  requirement  is  not  achievable  the  Requirements  Officer 
will  be  consulted  to  determine  if  a  lesser  requirement  can  be  stated. 

On  some  projects  the  SOR  and  Spec  develop  in  parallel  with  constant  communication  between  the 
PD  and  PM  staff.  On  these  projects  prototype  products  that  are  obtained  or  developed  are  often 
used  by  the  PD  staff  in  DLR  to  conduct  user  trials  with  soldiers  at  the  Units,  and  then  used  by  the 


Page  14 


SOR-Spec  Maker  Final  Report 


Humansyjte/ws  Incorporated 


PM  staff  in  ADM(Mat)  to  conduct  engineering  trials  to  evaluate  the  feasibility  of  technical 
specifications. 

On  other  projects  the  SOR  is  developed  entirely  by  DLR  staff  and  then  is  “  passed  off’  to  the  PM 
side  of  the  procurement  process  for  interpretation  and  Spec  development. 

Regardless  of  the  process,  once  the  Spec  is  completed  it  is  attached  to  a  Statement  of  Work  and 
contractual  requirements  to  form  a  Request  for  Proposal  (RFP)  which  is  sent  out  for  industry  to 
bid  on. 


3.1.9  Bid  Evaluation  and  Contract  Award 

When  bids  are  received  from  industry  the  project  team  assembles  a  bid  evaluation  team.  Most 
often  this  will  include  the  DLR  Requirements  Officer. 

The  method  used  for  bid  evaluation  is  dictated  by  the  DND  procurement  strategies  current  at  the 
time  of  evaluation.  These  strategies  are  established  by  ADM(Mat)  and  Treasury  Board  personnel 
and  can  change  with  changes  in  personnel  at  senior  levels  in  these  organizations. 

Two  major  techniques  have  historically  been  used  in  the  bid  evaluation  process.  Best  Value  and 
Lowest  Compliant  Bid.  Best  Value  evaluation  attempts  to  score  a  bid  against  a  set  of  prioritized 
requirements  to  establish  a  technical  score,  after  which  the  dollar  amount  of  the  bid  is  divided  by 
this  score  to  determine  the  best  technical  proposal  per  dollar  spent.  This  technique  is  used  less  and 
less  and  has  not  been  used  in  recent  years. 

Lowest  Compliant  Bid  evaluation  techniques  attempt  to  determine  which  bid  presents  the  “Lowest 
Cost  to  Meet  the  Minimum  Requirement.  With  The  Best  Industrial  Benefits” .  In  this  case  the 
requirements  prioritized  as  “Essential”  are  used  to  determine  all  the  bids  that  meet  these  essential 
or  minimum  requirements.  Then,  the  lowest  cost  bid  from  this  group  is  selected.  This  technique 
has  been  used  most  in  recent  years. 

Once  the  winning  bid  has  been  determined  a  contract  is  signed  and  the  Implementation  phase  of  a 
project  begins.  This  process,  and  the  subsequent  implementation,  will  be  conducted  under  the 
guidance  of  the  Project  Charter,  which  would  have  been  established  in  the  Development  Phase, 
and  a  Project  Implementation  Plan  developed  by  DND.  These  documents  establish  a  number  of 
roles  in  the  implementation  phase  and  designate  individuals  responsible  for  them.  Example  roles 
include  management,  requirements  issues,  testing,  quality  control,  training,  doctrine  development, 
etc.. 

3.1.10  Tracking  Requirements  During  Implementation 

Throughout  the  Implementation  phase,  requirements  and  specifications  are  monitored  and  updated 
by  the  DLR  and  Engineering  staff  respectively.  The  focus  of  this  activity  is  generally  on  the 
specifications  upon  which  the  contract  is  based.  As  design  details  are  completed  or  prototype 
products  are  created  and  tested  the  impact  on  requirements  is  tracked  by  these  DND  personnel.  If 
changes  are  required  to  the  details  of  a  specification  the  DLR  Requirements  Officer  will  get 
involved  in  the  review  of  the  issues  and  participate  in  design  trade  off  analysis  to  approve  any 
resulting  changes  to  the  requirements. 
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This  tracking  process  requires  that  some  form  of  “  link”  be  maintained  between  the  specifications 
and  the  requirements  from  which  they  were  derived.  In  some  projects  this  link  is  not  documented 
but  is  re-evaluated  as  necessary  (eg:  specification  “x”  cannot  be  met,  therefore  analyze  what 
requirement  this  will  impact).  On  other  projects  this  link  is  tracked  explicitly  at  all  times.  An 
example  in  this  category  is  the  Land  Force  Command  System  (LFCS)  which  has  developed  a 
requirement  and  specification  database  that  allows  all  of  the  links  between  and  within  the 
requirements  and  specification  sets  to  be  monitored. 

During  final  design  and  prototype  testing  it  is  often  necessary  for  DLR  to  approve  the  design 
and/or  to  select  between  design  options  in  terms  of  which  will  best  meet  the  “  users  need” .  In 
these  cases  the  Requirements  Officer  may  simply  ask  some  questions  and  decide,  or  he/she  may 
go  to  the  units  in  the  field  and  conduct  user  trials  to  actually  determine  the  impact  of  different 
design  alternatives  on  future  task  performance. 

Once  a  product  is  finalized  it  will  go  into  production.  During  production  the  quality  assurance 
staff  from  DND  will  select  items  from  each  production  run  and  conduct  tests  against  the 
performance  specification.  The  results  of  these  tests  are  communicated  throughout  the  project 
team.  Typically  the  DLR  staff  simply  review  these  for  information  and  only  get  involved  if  tests 
are  failing  at  which  time  several  personnel  may  get  involved  to  resolve  the  issues. 

3.1.11  Integration  of  Human  Factors  in  the  SOR  and  Spec 

One  of  the  focuses  of  this  project  was  to  determine  mechanisms  to  better  integrate  human  factors 
into  the  requirements  documented  in  the  SOR.  Therefore,  interviews  with  project  staff  and  SOR 
reviews  explored  the  current  state  of  human  factors  integration. 

To  evaluate  the  integration  of  human  factors  it  was  first  necessary  to  define  the  potential 
requirement  categories  that  could  be  derived  from  human  factors  analysis.  This  can  be  done  using 
a  number  of  human  factors  frameworks,  two  of  which  are  illustrated  in  Figure  5. 

On  the  left  of  Figure  5  is  the  basis  for  the  United  States  MANPRINT  process,  with  the  human 
factors  focus  being  on  whether  the  user  population  equipped  with  the  developed  tools  can  perform 
the  necessary  tasks  in  the  full  range  of  operational  environments.  The  role  of  human  factors  in  this 
case  is  to  analyze  each  of  the  these  areas  to  determine  the  requirements  of  a  future  system  to 
ensure  a  systematic  integration  of  all  factors. 

On  the  right  of  Figure  5  is  the  Person  Process  Environment  Model  which  expresses  the  same 
concept  in  more  detailed  terms.  The  PPE  Model  suggests  that  the  users  of  a  future  system  or 
product  will  be  participating  as  part  of  a  process  to  complete  operational  tasks,  with  the  two  key 
interfaces  being  the  information  interface  and  the  control  interface.  The  role  of  human  factors  is 
to  determine  the  requirements  of  a  future  system  within  this  context  in  terms  of  task  performance, 
interface  design,  user  characteristics,  physical  environment  factors,  training  factors,  and 
organizational  factors. 
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Figure  5:  Frameworks  for  Human  Factors  Issues 


To  effectively  consider  and  integrate  these  human  factors  issues  in  the  development  or 
procurement  cycle  of  new  products  and  systems  a  number  of  analysis  tasks  are  typically 
conducted.  Example  tasks  in  this  area  include  scenario  development,  function  and  task  analysis, 
interface  design  prototyping  and  reviews,  user  trials,  and  performance  evaluations.  Figure  6 
illustrates  the  integration  of  human  factors  activities  into  the  development  cycle  of  a  recent 
clothing  and  equipment  system. 
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Figure  6:  Example  Integration  of  Human  Factors  in  the  Development  Cycle 

( DND  Clothing  and  Equipment  Project) 
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Regardless  of  the  model  used,  there  are  a  number  of  issues  that  will  be  addressed  through  the 
consideration  of  human  factors  during  the  requirements  development  process.  Example  issues 
include: 

1 .  Operability, 

Which  generates  requirements  in  areas  such  as: 

•  Organization,  Personnel  and  Training  Characteristics 

■  Organizational  Structure  in  Relation  to  Mission/Scenarios 

■  Staffing,  Required  Experience,  Training,  Skills,  and  Ability 

•  Soldier  or  Crew  Task  Performance 

■  Task  Performance  -  Speed/Accuracy,  Fit,  Usability 

■  Workload  and  Situational  Awareness 

•  Soldier-Machine  Interface  and/or  Crew  Station  Layout 

■  Major  Display  and  Control  Requirements  for  Each  Major  Station 

■  Major  Crew  Station  Layout  Requirements 

■  Access/Egress,  Arrangement  Issues,  Key  Interfaces  by  Crew  Member 

•  User  Acceptance 

*  Perceived  Ease  of  Use,  Perceived  Utility 

■  User  Evaluation  Requirements 

2.  Maintainability 

Which  generates  requirements  in  areas  such  as: 

•  Task  Performance  (Speed/Accuracy),  Training  Requirements,  Personnel  Requirements 

•  Staffing  Requirements,  Skills  and  Training  Requirements,  Work  Flow 

•  Technology,  Decision  Aids 

3.  Reliability/Safety/Health 

Which  generates  requirements  in  areas  such  as: 

•  Environmental  Protection  (Temperature,  Lighting,  Noise,  Chemical) 

•  Physical  and  Mental  Demands  with  Variations  in  Op  Tempo 

•  Sustained  Operations,  Fatigue 

•  Human  Error  Requirements  or  Limitations 

4.  Availability  &  Survivability 

Which  generates  requirements  in  areas  such  as: 

•  Protective  Clothing  and  Equipment 

•  Sustained  Operations,  Fatigue 

•  Human  Availability  and  Survivability  (Care,  Food) 
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To  systematically  address  these  issues  within  the  life  cycle  of  a  product  or  system  a  number  of 
human  factors  analyses  are  typically  conducted.  These  include  activities  such  as  the  analysis  of 
operational  scenarios  to  determine  the  functions  and  tasks  that  a  user  will  perform.  Overall,  these 
lead  to  a  user  centred  approach  to  product  development  whereby  user  requirements  and  interface 
design  specifications  are  derived  from  analysis  of  tasks  within  the  range  of  operational 
environments.  These  requirements  and  specifications  are  then  validated  using  concepts, 
prototypes,  and  final  products  evaluated  through  user  trials. 

The  integration  of  human  factors  in  product  development  is  increasing  in  the  Land  Forces.  Data 
from  interviews  indicated  that  Requirements  Officers  are  increasingly  involved  in  user  centred 
design  processes,  mainly  in  the  area  of  user  trials  of  concepts,  paper  drawings,  prototype  products, 
or  near  final  products. 

That  said,  there  is  by  no  means  a  systematic  integration  of  human  factors  issues  across  DLR  in  the 
requirements  development  process.  Analysis  of  the  requirements  development  process,  and 
interviews  with  D.C.I.E.M.  personnel,  indicate  that  there  is  room  for  improvement  in  a  number  of 
areas,  including: 

•  A  Systematic  Application  of  Human  Factors  in  the  Requirements  Development  Process 

•  A  Systematic  Link  Between  Missions-Tasks-Requirements 

•  The  Use  of  Task  Analysis  to  Extract  User  Requirements 

•  A  More  Complete  Consideration  of  the  Full  Range  of  Environmental  Factors 

•  Consideration  of  the  Range  of  Future  User  Characteristics 

•  Validation  of  Requirements  Through  Focus  Groups  and  Trials  with  Future  Users 

•  User  Testing  of  Prototypes  and  Finals 


The  analysis  of  current  development  projects  indicated  that  there  are  some  good  examples  of 
human  factors  integration.  These  projects  demonstrated  some  elements  of  a  user  centred  analysis 
process,  resulting  in  iterative  development  of  requirements  following  user  review  of  concepts, 
prototypes,  or  buy-and-tiy  products.  Example  products  in  this  category  included: 

•  Soldiers  Helmet  and  Helmet  Subsystems  (D.  Palmer,  I.  Craigie),  which  has  produced  a 
good  task  oriented  specification  resulting  from  iterative  development  with  the  user 
community. 

•  Clothe  the  Soldier  (N.  Matem,  C.  Davis),  which  continues  to  involve  the  user  community 
to  evaluate  prototype  products  to  refine  requirements  and  specifications  in  parallel. 

•  Land  Force  Command  System  (A.  Gautier),  which  benefits  from  user  validated 
requirements  developed  over  several  years  through  the  Requirements  Officer’s  previous 
experience  with  iterative  development  at  units,  and  user  groups  continued  during  the  final 
stages  of  SOR  development. 
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3.1.12  The  Technical  Staff  Course  in  Kingston 

The  Technical  Staff  Course  in  Kingston  provides  officers  with  education  in  the  technology  of 
military  systems.  This  program  is  one  of  the  desirable  qualifications  of  a  DLR  Requirements 
Officer.  Interviews  with  Kingston  instructors  during  this  project  focused  on  two  areas;  the 
development  of  SORs,  and  the  integration  of  human  factors  in  the  development  of  new  systems. 

There  is  no  formal  SOR  Writing  Module  in  the  program  at  Kingston,  as  it  is  considered  too 
resource  intensive  to  develop  the  teaching  and  project  materials  for  full  SOR  development. 
However,  students  get  a  range  of  exposure  to  the  development  of  SOR  content  through  the  other 
modules  in  the  course.  This  is  accomplished  through  the  development  of: 

•  A  Deficiency  Memo  in  one  module,  whereby  the  student  must  justify  the  creation  of  a  new 
project  based  on  a  deficiency  in  operational  capability. 

•  A  series  of  Annexes  to  SORs  on  other  modules,  whereby  the  student  must  generate  the 
requirements  for  one  aspect  of  a  system  as  an  Annex.  For  example,  in  the  NBC  module  of 
the  course  the  students  learn  about  NBC  technology  and  then  develop  an  NBC  Annex  for  a 
system. 

Throughout  this  instruction  students  are  provided  with  some  guidance  about  the  development  of 
SORs.  This  guidance  is  high  level  to  help  the  student  develop  an  overall  approach  to  SOR 
development.  Example  guiding  principles  include: 

•  The  SOR  Should  Focus  on  the  Identification  of  the  True  Requirement 

•  The  SOR  Should  Identify  All  the  Requirements  to  Meet  a  Deficiency,  Even  If  They  Can’t 
Be  Fulfilled  at  this  Time 

•  The  SOR  is  a  Description  of  a  Need,  Not  Necessarily  What  You  Get 

•  The  SOR  is  an  Iterative  Document  in  order  to  Keep  Up  With  Technology 

•  The  Definition  of  an  Essential  and  Desirable  Requirement  is  Key 

•  There  is  No  Template  for  SOR  Format,  Each  Officer  will  have  to  Develop  Their  Own. 

One  of  the  modules  in  the  Kingston  program  is  a  Human  Factors  module.  This  module  introduces 
the  students  to  the  science  of  Human  Factors  with  the  goal  of  identifying  that  Human  Factors 
exists,  and  to  provide  the  students  with  a  familiarity  with  key  issues  (eg:  Man-Machine  Interfaces, 
Data  Displays,  Ergonomics).  The  module  contains  lecture  material  on  Human  Factors,  an 
orientation  visit  to  the  Defence  and  Civil  Institute  of  Environmental  Medicine  (D.C.I.E.M.),  and 
an  exercise  to  develop  a  Human  Factors  Annex  to  an  SOR.  The  exercise  component  provides  the 
students  with  an  SOR  for  an  old  Armoured  Personnel  Carrier  (APC)  and  requires  them  to  review  it 
to  identify  any  Human  Factors  requirements  that  it  contains  or  that  it  is  missing,  and  then  compile 
these  APC  Human  Factors  Requirements  into  a  Human  Factors  Annex. 

As  a  result  of  this  module,  the  new  generation  of  Requirements  Officer  in  DLR  is  more  familiar 
with  Human  Factors  issues  and  they  are  seeking  to  learn  more  about  methods  to  integrate  user 
needs  into  the  development  of  SORs  and  Specs. 
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3.2  Deficiencies  and  Requirements 

This  section  of  the  report  outlines  the  improvements  that  can  be  made  to  the  SOR  development 
process,  the  enhancements  that  can  be  made  to  the  SOR-Template,  and  the  requirements  for  SOR- 
Spec  Maker  software. 

To  organize  this  discussion,  and  the  corresponding  requirements  for  future  change,  deficiencies  in 
the  existing  system  have  been  identified.  For  the  purposes  of  this  project  a  “  Deficiency”  has  been 
defined  as: 

“A  condition  that  makes  it  more  difficult  for  the  Requirements  Officer  to 
generate  an  SOR,  or  a  situation  that  decreases  the  quality  of  the  SOR  in  terms  of 
its  ability  to  meet  the  “true  ”  users  requirement  in  the  field.  ” 

This  definition  suggests  that  the  issues  discussed  throughout  this  section  as  “  Deficiencies”  are 
included  because  they  impede  the  development  of  requirements  and  SORs.  It  is  important  to  note 
that  these  conditions  may  exist  for  perfectly  valid  or  understandable  reasons  from  other 
perspectives,  however,  they  are  deficiencies  when  examining  the  system  from  the  SOR 
perspective. 

The  deficiencies  identified  throughout  the  project  have  been  organized  into  groups  to  facilitate 
discussion  and  the  linkage  with  future  requirements.  The  deficiency  groups  in  this  section 
include: 

•  DLR  and  Army  Culture 

•  Lack  of  Scenarios,  Doctrine,  and  Operational  Concepts 

•  Access  to  Information  and  Resources 

•  SOR  Development  Process 

•  SOR  Format 

•  Integration  of  Human  Factors  in  the  SOR 

•  The  Link  with  ADM(Mat) 

•  Requirements  Traceability 

Following  the  description  of  each  group  of  deficiencies,  the  requirements  for  future  change  are 
outlined.  These  requirements  are  grouped  into  three  categories: 

•  Process  Requirements,  which  outline  the  requirements  for  change  in  the  process  followed 
to  develop  SORs  and  Specs. 

•  SOR  Template  Requirements,  which  outline  the  requirements  for  the  SOR  format 
Template  in  order  to  address  deficiencies  in  the  current  system. 

•  SOR-Spec  Maker  Requirements,  which  include  the  requirements  for  future  Requirements 
Management  software  and  thereby  define  the  role  for  such  software  in  the  SOR  and  Spec 
development  process. 
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3.2.1  DLR  and  Army  Procurement  Culture 

There  are  a  number  of  characteristics  of  the  military  environment  and  the  culture  within  DLR  that 
make  it  challenging  for  the  Requirements  Officer  to  effectively  support  the  development  of  SORs 
and  Specs.  Example  issues  in  this  category  include: 

1 .  A  Wide  Range  of  Project  Influences  and  Rationale. 

There  are  a  number  of  reasons  that  a  project  exists  within  DLR  and  a  number  of  personnel 
or  government  branches  that  feel  they  have  a  ‘stake’  in  a  project.  As  a  result,  the 
Requirements  Officer  is  often  pulled  in  many  directions,  and  no  two  projects  are  ever 
likely  to  be  the  same.  This  makes  it  difficult  to  pass  on  lessons  learned  to  other  officers. 

2.  The  Impact  of  the  Posting  Cycle 

DLR  staff  are  typically  in  their  positions  for  2  to  6  years,  however  a  project  can  last 
decades  depending  on  its  success  in  the  ever  changing  list  of  priorities  for  funding. 
Therefore,  the  Requirements  Officer  or  Project  Director  staff  is  likely  to  change  at  some 
point  in  the  project  life  cycle.  This  change  can  lead  to  gaps  in  project  knowledge  and  in 
the  ability  to  understand,  justify,  or  track  requirements. 

3 .  The  Need  to  Innovate,  Not  Implement. 

The  culture,  and  human  nature,  produces  a  need  for  the  Requirements  Officer  to  innovate. 
When  officers  are  in  charge  of  a  project  they  have  a  need  to  make  it  “theirs”  and  to  be 
recognized  for  their  efforts.  This  need  interferes  with  any  opportunity  that  might  exist  to 
recognize  that  the  previous  person  in  the  job  might  have  mapped  out  a  solid  plan  and  a 
solid  requirements  set  that  should  simply  just  be  implemented.  When  this  condition  is 
combined  with  the  posting  cycle  the  direction  of  a  project  is  highly  likely  to  change  at 
some  point  leading  to  confusion  and  traceability  problems. 

4.  Personality  Driven  Procurement  Priorities. 

The  military  procurement  system  is  not  driven  by  a  documented  set  of  deficiencies  or 
objectives  (see  Section  3.2.2),  which,  when  combined  with  points  #1,2,  and  3  above  leads 
to  personality  driven  procurement  priorities.  This  means  that  every  few  years  the  priority 
of  projects  for  funding  will  change  depending  on  who  is  posted  into  what  positions.  As  a 
result,  it  can  be  difficult  for  DLR  staff  to  guide  their  project  through  the  system  which  can 
deter  their  ability  to  develop  requirements  as  they  spend  more  and  more  time  on  the 
administration  of  a  project. 

5.  The  Need  to  Represent  the  Entire  Army. 

A  Requirements  Officer  is  most  often  from  the  Combat  Arms  and  is  likely  to  have  recent 
operational  experience.  However,  the  environment  or  culture  appears  to  require  this 
person  to  know  everything  about  the  entire  army,  let  alone  everything  about  his/her  own 
arm  of  it.  This  has  a  tremendous  negative  impact  on  the  quality  of  requirements,  as 
someone  who  has  never  completed  a  task,  or  who  hasn’t  completed  it  for  over  5  years,  is 
required  to  “  decide”  how  a  system  should  operate  in  support  of  the  task. 
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3. 2.1.1  Process  Requirements 

There  are  a  number  of  process  related  changes  that  can  address  these  deficiencies, 
including: 

1 .  Develop  a  Process  Bigger  Than  Any  One  Individual. 

A  documented  SOR  development  process  should  be  created  that  introduces  some  key 
milestones  in  the  development  of  an  SOR.  This  process  should  be  flexible  enough  to 
accommodate  the  wide  range  of  project  types,  but  formal  enough  that  project  staff  can 
understand  where  each  other  are  in  their  project  sequence.  This  process  should 
include  systematic  analysis  of  requirements,  validation  with  the  user  community,  and 
documentation  of  requirement  rationale,  all  of  which  make  it  difficult  for  any  one 
person  to  change  the  track  of  a  project  without  evidence. 

2.  Define  the  DLR  Requirements  Officer  as  a  Coordinator. 

The  role  of  the  DLR  Requirements  Officer  should  be  officially  defined  as  that  of  a 
coordinator.  This  role  requires  the  officer  to  organize  the  integration  of  a  wide  range 
of  user  and  technical  specialist  input  into  a  requirements  document,  and  does  not 
require  the  officer  to  be  the  sole  knowledge  source  behind  a  system. 

3.  Create  a  Project  “Team”  From  Day  1. 

In  the  current  system  a  Project  Implementation  Team  is  created  once  a  project  goes 
out  for  bid.  This  team  identifies  a  number  of  support  personnel  for  a  project  including 
requirements,  training,  doctrine,  fielding,  engineering,  etc..  These  same  roles  should 
be  defined  at  SS(ID)  such  that  the  requirements  coordinator  (the  DLR  officer)  has 
—  identified  personnel  who  will  expect  him/her  to  call  for  input  during  the  requirements 
development  process.  These  team  members  (in  a  matrix  approach)  will  include 
representatives  from  Doctrine/Operational  Concepts,  User  Tasks  (Ops  & 
Maintenance),  Deficiencies/Lessons  Learned,  Requirements,  Project 
Management/Engineering,  Research  Resources  (Personnel/Data/Studies),  Quality 
Assurance,  Public  Works  and  Government  Services  Canada  (PWGSC),  Training, 
Staffing,  and  Deployment.  Many  of  these  personnel  will  only  be  called  upon  to 
review  an  SOR  or  provide  some  quick  input,  but  input  from  all  of  these  groups  will 
increase  the  quality  of  the  requirements  set  and  prevent  re-work  at  the  last  minute. 

3. 2.1. 2  SOR  Template  Requirements 

Changes  to  future  SOR  Templates  that  could  address  the  deficiencies  identified  in  this 
group  include: 

1 .  Identify  the  Project  Team  Members  on  the  SOR. 

Each  of  the  personnel  identified  to  support  a  project  should  be  listed  on  one  of  the 
cover  sheets  of  the  SOR.  This  formally  recognizes  the  DLR  Officer  as  the  coordinator 
with  multiple  technical  inputs,  and  clearly  identifies  those  expected  to  provide 
technical  input. 
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3.2. 1.3  SOR-Spec  Maker  Requirements 

To  address  the  deficiencies  identified  in  this  group,  the  SOR-Spec  Maker  software  should: 

1 .  Provide  a  template  to  identify  all  key  project  support  personnel,  with  contact 
information  for  each,  including  a  direct  e-mail  link. 

3.2.2  Lack  of  Scenarios,  Doctrine,  and  Operational  Concepts 

Products  such  as  scenarios,  doctrine  and  future  operational  concepts  provide  the  data  necessary  to 
give  structure  to  the  procurement  process.  In  theory  the  Canadian  Land  Forces  exist  to  perform  a 
set  of  known  tasks  within  the  context  of  operational  scenarios  that  Canada  is  likely  to  participate 
in.  Within  these  scenarios  are  the  likely  operational  environments  and  threats  that  our  forces  are 
expected  to  encounter.  Looking  ahead  to  participation  in  these  scenarios  there  is  a  set  of  doctrine 
that  defines  how  the  forces  will  be  organized,  how  they  will  deploy,  and  how  they  will  act  against 
these  different  threats.  Combined,  this  data  can  define  the  operational  concept  for  future  systems 
to  participate  in  these  scenarios  and  provide  the  basis  for  the  analysis  of  the  requirements  for  these 
future  systems.  Unfortunately,  very  little  of  this  information  exists. 

The  DLR  Requirements  Officer  is  typically  from  the  Combat  Arms  and  usually  has  recent 
operational  experience.  As  a  result  these  personnel  are  very  knowledgeable  in  military  operations 
and  task  performance,  and  if  given  a  military  scenario  they  can  analyze  it  to  extract  the  key  factors 
related  to  mission  success.  If  scenarios,  future  doctrine,  and  operational  concepts  did  exist  the 
DLR  staff  would  have  a  framework  to  guide  their  analysis  of  future  requirements.  In  addition, 
there  would  be  a  force  wide  knowledge  of  requirements  that  would  allow  prioritization  across 
projects  in  terms  of  their  relative  importance  to  provide  operational  capability  across  the  defined 
set  of  Canadian  operational  scenarios  and  the  current  list  of  Army  deficiencies. 

As  there  are  no  defined  scenarios,  future  doctrine,  or  operational  concepts,  the  DLR  staff  are  often 
required  to  generate  this  data  on  their  own.  In  this  situation  a  Captain  has  been  tasked  with  the 
development  of  the  SOR  for  a  future  system,  but  must  also  invent  how  the  Land  Forces  might  use 
this  system  at  the  same  time.  This  makes  it  very  difficult  to  develop  requirements  and  can  also  be 
quite  time  consuming.  The  result  is  that  there  are  a  number  of  SORs  in  the  system  that  define 
hundreds  of  requirements  for  a  system  but  provide  no  documentation  of  how  Canada  will  use  the 
system  (Missions,  Scenarios,  Tasks,  Organization,  Deployment)  in  the  future.  This  leads  to  the 
procurement  of  multi-million  dollar  systems  being  delivered  to  the  units  who  then  start  the  process 
of  determining  how  it  will  fit  into  operations. 

Related  to  this  lack  of  future  operational  context  is  a  lack  of  systematic  analysis  to  derive 
requirements  for  future  systems.  There  is  very  little  evidence  of  analysis  of  missions,  scenarios, 
and  tasks  to  extract  requirements  and/or  to  develop  the  key  performance  requirements  to  be  used 
during  system  testing.  This  is  partly  due  to  the  lack  of  scenario  data,  and  partly  due  to  a  lack  of 
understanding  of  how  to  conduct  task  analysis  to  extract  user  requirements  for  future  systems. 
Some  projects  who  recognize  the  need  for  this  analysis  have  started  to  contract  support  through 
D.C.I.E.M.  and  human  factors  firms  to  develop  scenarios  and  interact  with  future  users  to  conduct 
task  analysis  and  develop  requirements. 
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3. 2.2.1  Process  Requirements 

There  are  a  number  of  required  enhancements  to  the  SOR  development  process  in  order  to 
address  the  need  for  structured  data  sets  to  guide  requirements  analysis,  including: 

1 .  Develop  Army  Wide  Scenarios/Missions 

The  Canadian  Forces  should  provide  a  series  of  standardized  missions  and  scenarios 
that  they  expect  the  Land  Forces  to  support.  Over  time  the  different  arms  should 
analyze  how  they  would  deploy  to  support  these  scenarios  in  the  future,  with  support 
from  the  Directorate  of  Army  Doctrine  and  Future  Concept  Groups.  This  information 
should  be  documented  and  integrated  into  the  instruction  program  at  the  Kingston 
Tech  Staff  School. 

2.  Identify  and  Prioritize  Army  Wide  Requirements 

Based  on  the  Force  wide  scenarios,  a  set  of  deficiencies  should  be  maintained  that 
provides  a  prioritized  list  of  deficiencies  that  DLR  needs  to  address.  This  list  should 
then  be  used  as  one  input  to  guide  the  allocation  of  resources.  This  would  not  only 
provide  structure  and  some  predictability  to  the  requirements  analysis  process,  but 
would  also  address  some  of  the  concerns  discussed  in  Section  3.2.1  related  to 
personality  driven  procurement  priorities. 

3.  DND  Provide  DLR  with  Doctrine  and  Future  CONOPS  Support 

DLR  staff  should  be  provided  with  links  to  personnel  in  the  Directorate  of  Arm 
Doctrine  and  the  Future  Concepts  group  at  the  start  of  the  project  SS(ID)  or  prior  to 
when  the  SOR  will  be  developed.  These  personnel  should  provide  guidance  on  where 
the  project  fits  in  to  future  operations  and  how  it  is  likely  to  be  deployed  within  the 
standard  force  scenarios. 

4.  Task  Analyze  to  Develop  Requirements 

Once  future  scenarios  and  operational  concepts  are  defined  for  a  project  they  should 
be  task  analyzed  to  determine  the  user  requirements  for  the  future  system.  This 
analysis  should  focus  on  the  “  What?”  aspects  of  future  task  performance  (i.e.  what 
the  system  needs  to  do  to  support  future  task  performance),  and  not  on  the  “How?” . 
This  analysis  should  also  produce  some  user  requirements  in  the  form  of  the 
performance  measures  and  scenario  vignettes  necessary  to  develop  user  centred 
product  acceptance  trials. 

3.2.2.2  SOR  Template  Requirements 

To  address  the  deficiencies  in  this  group  the  template  for  SOR  format  should: 

1.  Include  standard  sections  on  Missions/Scenarios,  Operational  Concepts,  and  Key 
Tasks  where  the  Requirements  Officer  can  summarize  the  future  operational  context 
for  the  system. 

2.  Ensure  that  all  SOR  section  titles  in  the  template  are  mandatory,  with  “Not 
Applicable”  or  “Not  Available”  being  acceptable  input  with  an  associated  rationale. 
This  will  help  ensure  that  these  issues  are  addressed,  if  not  in  the  initial  development 
of  an  SOR,  then  through  the  review  process. 
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3.2.2.3  SOR-Spec  Maker  Requirements 

Assuming  the  above  requirements  are  implemented,  the  SOR-Spec  Maker  software 

should: 

1 .  Contain  the  standard  SOR  Template. 

2.  Ensure  that  all  section  titles  are  mandatory,  requiring  the  writer  to  fill  in  some  content 
or  state  “Not  Applicable”  or  “Not  Available”  with  rationale. 

3.  Contain  a  Missions/Scenario  section  that  provides  a  link  to  a  summary  of  the  Land 
Force  scenarios  that  the  system  must  support.  The  software  should  allow  this  scenario 
text  to  be  placed  in  the  Mission/Scenario  section  of  the  SOR  or  in  an  Annex 
depending  on  how  much  additional  data  the  Requirements  Officer  has  to  incorporate 
with  it. 

3.2.3  Access  to  Information  and  Resources 

The  SOR  development  process  involves  the  Requirements  Officer  searching  for  a  range  of 
information  to  integrate  into  the  SOR.  These  information  sources  (see  Section  3.1.6  and  Figure  3) 
are  contained  in  a  number  of  locations,  most  of  which  are  not  known  to  the  DLR  staff.  Interview 
data  from  this  project  indicated  that  DLR  personnel  can  take  3  months  or  more  searching  for 
information  related  to  their  requirements  set,  and  that  many  are  never  made  aware  of  resources 
that  might  be  available  (such  as  personnel  or  literature  at  Defence  Research  Establishments).  This 
search  for  information  is  less  of  a  problem  for  graduates  of  the  Kingston  Tech  Staff  School  as 
these  students  are  provided  with  a  solid  introduction  to  the  Canadian  Procurement  System,  but  it  is 
still  a  challenge  as  the  type  and  location  of  resources  constantly  change. 

One  key  area  of  requirements  development  is  understanding  the  relationship  between  the  system 
being  specified  and  other  future  products  or  systems  under  development.  If  this  relationship  is  not 
understood  multiple  systems  can  be  developed  to  support  similar  tasks  and  systems  can  be 
specified  that  will  not  work  together  within  the  same  future  scenario.  Interviews  with  project 
personnel  indicated  that  lack  of  a  system  wide  view  of  the  projects  within  DLR  is  a  very 
frustrating  aspect  of  the  posting  to  DLR.  Many  staff  reported  that  they  were  not  aware  that  their 
project  overlapped  with  others. 

In  addition  to  information  on  other  projects,  access  to  research  data  was  another  key  deficiency  in 
the  requirements  analysis  process.  One  component  of  this  was  lack  of  awareness  of  how  the  DREs 
were  organized,  what  expertise  they  had  to  offer,  and  what  previous  research  had  already  been 
conducted.  Another  DRE  related  deficiency  was  the  bias  of  different  cells  in  the  research 
establishments  and  the  impact  of  this  has  on  the  use  of  DRE  support.  This  second  concern  was 
expressed  by  DLR  staff  as  “  beware  of  the  DREs” ,  as  some  groups  have  a  research  bias  and  will 
attempt  to  integrate  a  “real”  problem  into  a  research  program  that  will  never  provide  the 
Requirements  Officer  with  answers.  On  the  other  hand  some  DRE  groups  are  focused  on  the 
development  of  products  and  patents  and  will  integrate  another  “real”  research  problem  into  the 
functionality  for  some  product  that  does  not  answer  requirements  questions  for  DLR.  In  addition, 
there  were  reports  of  DRE  cells  that  were  simply  not  interested  or  not  able  to  provide  technical 
support  to  DLR  project  teams.  In  general,  there  is  also  a  lack  of  comprehension  of  the 
Requirements  Development  Process  by  many  “scientists”,  and  therefore  a  lack  of  understanding 
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of  the  information  “  products”  required  by  DLR  teams  within  compressed  timelines.  All  of  these 
factors  make  it  difficult  to  integrate  research  data  into  the  development  of  an  SOR. 

3. 2.3.1  Process  Requirements 

In  order  to  provide  better  access  to  information  and  resources,  the  SOR  development 
process  should: 

1 .  Identify  Links  to  Information  for  Each  Project. 

Provide  the  Requirements  Officer  Links  to  a  range  of  information  sources,  including 
Army  Operations  (Scenarios),  Operational  Concepts,  Doctrine  and  Future  Concepts, 
and  Research  personnel. 

2.  Define  DRE  Role  to  Support  DLR  Projects 

There  is  a  need  to  define  the  role  for  DRE  staff  to  support  DLR  projects  and  to 
communicate  this  in  any  future  descriptions  of  the  SOR  Development  Process.  It 
would  appear  that  key  points  in  this  definition  should  be  that  DREs  must  support  DLR 
,  projects,  but  that  they  may  not  be  able  to  do  all  the  work  themselves  at  which  point 
they  may  be  required  to  act  as  technical  experts  to  help  select  or  supervise  contract 
personnel. 

----- -  3.  Train  Scientists  on  the  Development  Process. 

The  Scientific  Authorities  in  the  DREs  should  be  provided  with  training  on  the  System 
Development  cycle  and  the  SOR-Spec  Development  Process.  This  training  should 
emphasize  the  information  “products”  that  DLR  staff  require  and  the  typical  timelines 
that  they  are  being  asked  to  work  within. 

3.2.3.2  SOR  Template  Requirements 

To  support  the  integration  of  related  requirements  across  projects,  the  SOR  Template 
should: 

1 .  Contain  a  Required  Section  that  Identifies  Related  Projects 

3.2.3.3  SOR-Spec  Maker  Requirements 

To  address  the  need  for  access  for  a  wide  range  of  information  sources,  SOR-Maker 
software  should: 

1.  Provide  software  links  to  as  many  information  sources  as  possible  from  one  common 
Information  Link  tool.  The  data  required  by  DLR  officers  is  increasingly  being 
produced  in  electronic  form,  which  increases  the  future  utility  of  a  software  based  link 
to  information.  These  links  may  be  based  on  data  available  on  CD-ROMs  or  over 
Intranet  sites.  A  role  should  be  defined  within  DLR  Coordination  to  monitor 
electronic  information  sources  and  continually  update  these  links  for  the  project 
teams.  Example  links  for  this  tool  include: 

•  Doctrine  (Electronic  Battle  Box  CD,  Others...) 

•  Task  Data  from  Soldiers  Day,  or  Other  DND  Documents 

•  Literature  (Research,  Studies) 

•  Past  SORs,  Related  SORs 
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•  Design  Standards,  Test  Methods,  Test  Criteria 

•  Lessons  Learned  CD-ROMs  or  Databases 

•  Deficiencies  in  Existing  Systems  (eg:  The  Army  Combat  Clothing  and  Equipment 
Survey  System  (ACCESS),  or  UCRs) 

•  The  Defence  Research  Establishments 

2.  Develop  an  SOR-Spec  Library. 

Each  time  an  SOR  or  Spec  is  ‘frozen’  as  a  version  for  distribution  and  comment  the 
SOR-Spec  Maker  software  should  provide  a  facility  to  deposit  the  version  into  a 
library.  The  version  deposited  in  the  library  should  overwrite  the  last  version  that  was 
placed  there.  The  most  recent  version  of  an  SOR  or  Spec  should  remain  in  the  library 
for  10  years  unless  it  is  overwritten  by  a  more  recent  one.  The  library  should  contain 
a  search  engine  and  the  ability  to  copy  requirements  from  a  located  document  into  the 
current  SOR  or  Spec  under  development. 

3.2.4  SOR  Development  Process 

There  are  a  number  of  deficiencies  in  the  current  SOR  Development  Process  that  were  identified 
throughout  the  present  study,  including  the  lack  of  a  process,  and  lack  of  iteration  in  the  process. 

The  primary  deficiency  with  the  SOR  Development  Process  is  that  there  is  no  process  to  follow. 

As  a  result,  each  Requirements  Officer  must  develop  their  own  method  and  justify  each  step  of 
their  analysis  to  others.  This  can  take  up  a  considerable  amount  of  DLR  staff  time  if  they  decide, 
for  example,  that  they  should  validate  their  requirements  with  the  user  community  as  opposed  to 
simply  conducting  a  document  review. 

The  lack  of  a  common  process  also  makes  it  difficult  to  understand  where  different  projects  are  in 
the  process.  This  decreases  the  ability  to  share  information  across  projects,  and  makes  it  difficult 
to  manage  or  coordinate  the  activities  of  multiple  projects  engaged  in  different  processes. 

The  additional  deficiency  identified  in  this  group  was  that  there  is  little  iteration  in  the  SOR 
development  process  for  many  projects.  This  results  in  an  assumption  that  the  first  pass  through 
requirements  development  will  be  basically  correct,  and  provides  very  little  opportunity  to  validate 
requirements  with  future  users. 

This  second  deficiency  was  recently  commented  on  by  DG  Audit  in  their  assessment  of  the  Frag 
Vest  project  where  it  was  noted  that  the  $4.5  Million  spent  on  re-design  could  have  been  avoided 
if  the  user  trials  conducted  by  human  factors  personnel  were  completed  earlier  in  the  project  cycle, 
as  opposed  to  at  the  very  end  of  implementation  (Auditor  General  Report  1995). 

3.2.4.1  Process  Requirements 

To  address  these  process  related  deficiencies  there  are  a  number  requirements  for  future 
SOR  processes,  including: 

1 .  An  SOR  Development  Process  should  be  established,  documented,  and  taught.  This 
process  should  include  key  milestones  that  all  Requirements  Officers  should  pass 
through  in  the  development  of  SOR,  including  Mission/Scenario  Definition, 
Function/Task  Analysis,  Identification  of  Related  Projects,  Internal  SOR  Review, 
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Requirements  Validation  with  Units,  Evaluation  of  Requirements  through  Trials  of 
Prototypes  or  Mockups,  etc.. 

2.  Any  formal  SOR  Development  Process  should  include  the  requirement  for  review 
with  the  future  user  community  and  subsequent  requirement  iteration. 

3. 2.4.2  SOR  Template  Requirements 

No  SOR  Template  requirements  were  identified  to  specifically  enhance  the  SOR 
Development  process. 

3.2.4.3  SOR-Spec  Maker  Requirements 

To  support  a  structured  SOR  Development  Process,  with  key  milestones  common  across 
projects,  SOR-Spec  Maker  should: 

1 .  Provide  an  SOR  Development  Process  “  Wizard”  that  provides  the  outline  of  the  key 
steps  requirement  and  the  ability  for  the  Requirements  Officer  to  indicate  where  they 
are  in  the  process. 

2.  Provide  Dynamic  To-Do  Lists  for  the  Major  Milestones  and  Analysis  Required. 

3.  Provide  Context  Specific  Help  with  Pointers  to  DND  Support  Agencies  for  each  of  the 
major  milestones  that  should  be  covered  in  the  development  of  the  SOR. 

3.2.5  SOR  Format 

Similar  to  the  SOR  Development  Process,  the  major  deficiency  with  the  SOR  Format  is  that  there 
is  no  standardized  format  to  follow.  Interviews  throughout  the  project  identified  draft  versions  of 
“official”  SOR  formats,  as  part  of  draft  versions  of  CFP  125,  however  few  DLR  personnel  were 
aware  of  the  existence  of  these  templates. 

The  lack  of  an  SOR  Format  requires  each  project  to  develop  their  own  format  which  takes 
resources  and  adds  uncertainty  to  SOR  development.  In  addition,  it  encourages  projects  to  only 
develop  SOR  sections  for  which  they  have  content.  Therefore,  many  SORs  end  up  dropping 
sections  such  as  Missions,  Operational  Concepts,  and  Key  Tasks. 

The  other  deficiency  identified  with  the  format  of  SORs  is  that  the  various  forms  in  use  do  not 
support  the  evolutionary  development  of  requirements.  This  is  increasingly  common  in 
information  system  projects  that  must  “  grow”  requirements  over  time.  The  existing  formats  and 
the  management  of  the  SOR  documents  do  not  support  the  enhancement  of  requirements  as  they 
evolve,  expand,  or  collapse. 

3.2.5.1  Process  Requirements 

To  address  the  deficiencies  in  SOR  Format  the  following  modifications  to  the 
development  process  are  required: 

1 .  Develop  a  common  SOR  format  and  have  all  projects  follow  it.  This  does  not  appear 
to  be  an  unreasonable  requirement  as  all  SORs  reviewed  during  this  analysis  could  be 
reworked  into  a  common  format. 
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2.  Make  all  SOR  sections  mandatory,  with  Not  Applicable  or  Not  Available  as 
acceptable  inputs  to  SOR  sections  provided  there  is  a  reasonable  rationale  provided. 

3.  Encourage  the  Requirements  Officer  to  develop  the  full  requirement  for  a  system,  at 
least  on  the  first  few  passes,  to  ensure  that  the  full  range  of  requirement  are 
documented  at  least  once  for  future  reference. 

3.2.5.2  SOR  Template  Requirements 

There  is  one  key  requirement  to  address  the  deficiencies  in  SOR  Format: 

1 .  Develop  a  common  SOR  format  and  have  all  projects  follow  it. 

3.2.5.3  SOR-Spec  Maker  Requirements 

To  support  a  standardized  SOR  Format,  SOR-Spec  Maker  software  should: 

1 .  Provide  an  SOR  Template  Based  on  the  New  Common  SOR  Format. 

2.  Provide  On-Line  “Help”  on  SOR  Section  Contents. 

3.  Provide  On-Line  “Pointers”  to  Resources  within  DND  that  could  assist  in  the 
Completion  of  SOR  Sections. 

3.2.6  Integration  of  Human  Factors  in  the  SOR 

The  interviews  conducted  during  this  project  indicated  that  Requirements  Officers  are  increasingly 
aware  of  human  factors  issues,  and  increasingly  see  the  benefits  of  human  factors  analysis  based 
on  project  success.  However,  a  number  of  challenges  remain  in  regards  to  enhancing  their 
understanding  of  the  integration  of  human  factors  analysis  and  the  difficulty  associated  with 
locating  SOR  sections  to  contain  requirements  related  to  human  task  performance. 

3.2.6.1  Process  Requirements 

Several  process  requirements  can  be  derived  from  the  analysis  related  to  human  factors, 
including: 

1 .  The  requirements  development  process  needs  to  incorporate  standard  analysis 

milestones  related  to  systematic  analysis  of  user  requirements.  This  should  include: 

•  The  definition  of  missions  and  scenarios. 

•  The  develop  of  a  Concept  of  Operations  in  terms  of  how  personnel  will  use  the 
future  system  within  the  context  of  the  identified  missions  and  scenarios. 

•  Function  and  task  analysis  of  these  scenarios  to  extract  requirements. 

•  The  completion  of  a  User  Group(s)  at  operational  units  early  in  the  requirements 
development  process  to  validate  the  scenarios,  the  Concept  of  Operations,  and  the 
preliminary  requirements. 

•  The  completion  of  a  User  Trial(s)  later  in  the  requirements  development  process 
using  prototype  products,  storyboards  of  design  concepts,  or  buy  and  try  products. 
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•  The  integration  of  Human  Factors  standards  into  the  requirements  development 
process. 

•  The  completion  of  User  Trial(s)  during  Project  Implementation  to  validate 
detailed  design  concepts  and  to  provide  the  necessary  data  for  Trade  Off  studies 
when  choices  must  be  made  between  design  alternatives. 

2.  It  would  be  beneficial  if  there  was  a  qualified  human  factors  staff  member  in  Ottawa 
to  support  Land  Force  procurement.  This  officer  would  need  to  be  a  fully  qualified 
human  factors  professional  (according  to  industrial  certification  qualifications),  and 
would  be  available  to  provide  human  factors  support,  link  human  factors  requirements 
across  projects,  and  liase  with  D.C.I.E.M.  on  research  issues. 

3.2.6.1  SOR  Template  Requirements 

The  key  to  ensuring  that  human  factors  issues  are  integrated  in  the  SOR,  is  to  address  all 
the  aspects  of  the  system  that  will  impact  human  performance  and  ensure  the  requirements 
in  each  area  have  been  considered.  These  aspects  include  the  design  considerations  (task 
performance  under  a  range  of  operational  conditions),  the  personnel  and  training 
considerations,  and  the  organizational  considerations  in  terms  of  manning  and  major 
human  machine  interfaces  as  a  result  of  team  organization. 

To  meet  this  need  a  number  of  mandatory  sections  are  required  in  the  SOR  Template, 
including: 

1.  Related  Projects.  This  section  placed  early  in  the  document  identifies  the  other 
ongoing  projects  that  should  be  considered  to  ensure  that  the  future  user  will  have  an 
integrated  system  to  support  overall  mission  and  task  performance. 

2.  Missions,  and  Scenarios.  These  sections  outline,  at  least  at  a  high  level,  the  types  of 
operations  the  new  system  or  product  must  support.  These  descriptions  must  form  the 
basis  of  task  analysis  activities  to  extract  requirements,  and  the  basis  of  user  trial 
design  to  evaluate  concepts  with  future  users. 

3.  Concept  of  Operations.  This  section  outlines  how  the  future  system  will  be  used 
within  the  context  of  the  missions,  scenarios,  and  tasks.  This  information  outlines 
how  future  equipment  is  likely  to  operate,  how  it  will  be  staffed,  how  information  will 
flow  (in  the  case  of  information  systems,  and  the  major  soldier-machine  interfaces  that 
will  be  required  to  operate  the  system. 

4.  Key  Tasks.  This  sections  outlines  the  key  tasks  to  be  performed  at  each  of  the  major 
soldier-machine  interfaces,  when  using  the  system  in  support  of  the  future  concept  of 
operations,  within  the  design  basis  mission  and  scenarios.  These  are  the  critical  tasks 
that  analysis  must  be  based  on,  and  the  tasks  that  user  trials  must  replicate  to  evaluate 
system  performance  with  humans  in  the  loop. 

5.  Concept  of  Support.  This  section  outlines  the  organization  of  the  support  structure  to 
maintain  the  system,  the  major  support  positions  that  are  likely  to  be  required,  and 
identifies  the  key  support  tasks. 
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6.  User  Characteristics.  This  section  identifies  and  describes  the  key  characteristics  of 
the  user  population,  in  terms  of  both  operators  and  maintainers.  Example  user 
characteristics  include  age,  sex,  language,  education,  training,  size,  handedness, 
sensory  capabilities  (eg:  sight,  colour  vision,  hearing),  or  the  amount  and  type  of 
operational  experience.  References  for  these  characteristics  should  be  used  wherever 
possible  (eg:  description  of  training  levels  or  courses,  Canadian  Forces 
Anthropometric  studies,  or  selection  criteria).  The  range  of  the  population  in  each 
category  should  also  be  defined,  with  the  expected  design  goal  being  to  accommodate 
95%  of  the  future  user  population  through  the  acquisition  of  the  new  system  and  the 
training  to  accompany  it.  In  some  systems  ,with  small  numbers  of  pre-selected 
specialized  users  (eg:  pilots,  navigators,  divers),  the  system  should  accommodate 
100%  of  the  user  population 

7.  Human  Factors  Performance  Requirements.  Within  each  set  of  requirements  at  the 
system  or  sub-system  level  there  are  four  categories  of  requirements  that  must  be 
identified: 

•  Soldier  /  Crew  Task  Performance.  These  requirements  outline  the  key  task 
performance  characteristics  for  the  system  or  sub-system.  These  requirements 
describe  key  task  elements  that  the  future  user  must  be  able  to  complete,  and 
describe  the  speed,  accuracy,  and  usability  criteria  that  must  be  met  to  achieve 
adequate  system  performance  within  the  future  concept  of  operations. 

•  Soldier-Machine  Interface  /  Crew  Station.  These  requirement  outline  the  key 
equipment  interfaces  that  must  be  included  to  support  each  of  the  system  or 
sub-systems.  It  will  also  identify  any  critical  layout  requirements  related  to 
equipment  access,  the  range  of  the  population  that  must  be  accommodated 
according  to  a  number  of  parameters,  or  compartment  access  and  egress. 

•  System  Safety  /  Health  Hazards.  These  requirements  will  describe  the 
features  that  the  future  system  requires  to  ensure  the  safety  of  the  future  users. 

•  User  Acceptance.  These  requirements  describe  the  requirements  of  the  future 
system  to  ensure  user  acceptance,  and  details  any  future  user  testing 
requirements  to  evaluate  performance,  ease  of  user,  and  utility  of  proposed 
designs. 

8.  Personnel  and  Training.  These  requirements  relate  the  number  of  personnel  required 
to  operate  the  system,  the  characteristics  required  of  those  personnel,  and  the  details 
of  the  training  systems  and  programs  that  will  be  required  to  develop  skill  in  these 
future  users. 

3.2.6. 3  SOR-Spec  Maker  Requirements 

To  support  the  integration  of  human  factors  into  the  design  cycle,  the  SOR-Spec  Maker 

product  should: 

1 .  Produce  requirements  in  accordance  with  the  proposed  SOR  template. 


Wumansystems  Incorporated 


SOR-Spec  Maker  Final  Report 


Page  33 


2.  Provide  pointers  to  human  factors  support  agencies  (eg:DCIEM)  within  the  help 
system  for  the  product  in  relation  to  those  SOR  sections  related  to  human  factors 
issues. 

3.  Provide  links  to  Soldiers  Day  and  any  other  task  description  tools  available  to  support 
systematic  analysis  of  user  missions,  scenarios,  and  tasks,  or  to  provide  other  data 
such  as  a  Target  Audience  Description. 

3.2.7  The  Link  with  ADM(Mat) 

The  link  between  Project  Directing  staff  in  DLR  and  Project  Management  staff  in  ADM(Mat)  can 
have  a  variety  of  forms  depending  on  personalities  and  the  type  of  project.  Some  projects 
formalize  this  link  early  on  and  work  together  to  develop  requirements  and  specifications  in 
parallel,  while  others  simply  pass  documents  back  and  fourth  at  the  SS(EPA)  and  procurement 
stages  as  the  SOR  is  finalized  and  the  Spec  is  developed. 

Regardless  of  the  exact  nature  of  this  link,  it  is  a  weak  link  in  the  procurement  process  in  many 
cases.  Interviews  will  all  parties  indicated  that  there  is  often  a  “gap”  in  comprehension  during  the 
transition  from  an  SOR  to  a  Spec.  This  results  is  either  a  drawn  out  question  and  answer  period  as 
the  PM  staff  attempt  to  understand  what  was  intended  by  the  requirement,  or  the  PM  staff 
continuing  with  procurement  based  on  what  they  perceive  the  requirement  to  be.  Any  lack  of 
comprehension  also  makes  it  very  difficult  during  detailed  design  or  development  to  relate 
changes  in  specifications  back  to  the  requirements  that  they  impact.  In  combination  these  effects 
often  lead  to  bad  relations  as  the  DLR  staff  feel  that  a  product  or  system  has  been  procured  that 
does  not  meet  their  requirements. 

One  component  of  this  relationship  that  is  especially  challenging  is  the  impact  of  the  bid 
evaluation  methodology.  The  current  practice  is  to  evaluate  candidates  based  on  the  Lowest  Cost 
for  the  Minimum  Essential  Requirements  with  the  Best  Regional  Benefits.  It  is  generally 
understood  that  all  “Desirable”  requirements  will  simply  be  ignored  and  only  “Essential” 
requirements  will  be  used  in  the  development  of  the  Spec  and/or  in  bid  evaluation.  This  is  a  very 
large  distraction  for  the  DLR  officer  as  they  spend  a  considerable  amount  of  time  trying  to  re-word 
requirements  and  classify  them  as  “Essential”  or  “Desirable”. 

3. 2.7.1  Process  Requirements 

To  address  these  concerns  with  the  link  between  PD  and  PM  staff  a  number  of  changes  to 
the  process  are  required: 

1 .  Establish  the  Link  Between  the  PD  and  PM  Early  in  the  Process. 

The  few  projects  that  do  this  now  and  really  work  together  appear  to  really  understand 
each  other  better,  and  do  not  appear  to  have  to  revisit  issues  during  implementation. 

2.  Develop  the  SOR  and  Spec  in  Parallel. 

The  few  projects  who  do  this  appear  to  have  a  strong  relationship  between  the  PD  and 
PM  staff,  with  a  general  understanding  of  the  issues  driving  each  others  documents. 
The  DLR  staff  on  the  PD  side  understand  the  technical  testing  that  the  engineering 
staff  will  conduct  and  the  issues  related  to  the  feasibility  of  delivering  certain 
technologies,  while  the  engineering  staff  on  the  PM  side  develop  a  better 
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understanding  of  how  the  system  will  be  used  and  what  the  requirements  mean.  In 
these  situations  the  DLR  staff  appear  to  be  able  to  stay  focused  on  making  their 
document  a  statement  of  the  requirement  (the  “What”). 

3.  Conduct  User  Studies  and  Tech  Studies  in  Parallel  to  Validate  Requirements. 

When  the  PD  and  PM  staff  work  together  early  in  the  process  the  development  of 
operational  analysis  or  the  procurement  of  prototype  products  can  meet  both  their 
needs.  In  these  cases  focus  groups  with  users  can  answer  questions  of  interest  to  both 
parties,  while  prototype  products  can  be  tested  in  user  trials  to  validate  requirements 
and  then  tested  by  engineering  to  validate  specifications  and  testing  criteria. 

4.  Track  the  Relationship  Between  Requirements  and  Specifications. 

The  PD  and  PM  staff  should  track  the  link  between  requirements  and  specifications  to 
facilitate  assessments  of  the  impact  of  requirement  changes  on  specs  and  the  impact  of 
specification  changes  on  requirements. 

5.  Work  Towards  Best  Value  Bid  Evaluation  Methods. 

The  more  “Best  Value”  evaluation  methods  can  be  used,  the  more  “honest”  all 
parties  can  be  about  the  relative  priority  of  requirements  and  specs,  which  will 
decrease  the  time  spent  on  exact  wording  and  rating  while  providing  a  richer  base  of 
priorities  to  guide  procurement  decisions. 

3.2.7. 2  SOR-Template  Requirements 

There  were  no  SOR  Template  format  requirements  identified  to  support  the  PD  and  PM 

link. 

3.2.7. 3  SOR-Spec  Maker  Requirements 

To  support  the  link  between  the  PD  and  the  PM,  SOR-Spec  Maker  should  be  used  by  both 

parties,  and  the  software  should: 

1 .  Allow  the  DLR  staff  and  the  engineers  to  develop  the  requirements  and  specifications 
for  a  project  in  parallel. 

2.  Allow  the  DLR  staff  to  view  but  not  edit  specifications,  and  allow  the  engineers  to 
view  but  not  edit  the  requirements. 

3.  Provide  the  PM  staff  with  a  process  wizard  and  information  links  related  to  the 
specification  development  process.  Information  links  should  include  many  of  the 
same  resources  available  to  DLR  staff  in  addition  to  technical  standards  (Defence  and 
Industrial). 

4.  Allow  the  user  to  enter  and  edit  specifications. 

5.  Establish  and  track  a  link  between  the  latest  set  of  requirements  and  the  latest  set  of 
specifications. 

6.  Allow  the  user  to  merge  and  split  specifications  as  necessary,  while  maintaining  a 
consistent  numbering  system  and  maintaining  the  tracking  of  links  within 
requirements,  within  specifications,  and  between  specifications  and  requirements. 
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7.  Allow  the  user  to  indicate  the  interdependency  between  requirements  and  therefore 
between  specifications,  and  then  track  this  interdependency. 

8.  Allow  the  user  to  describe  how  specifications  will  be  tested,  develop  summaries  of 
specification  tests,  and  track  whether  specifications  are  passing  tests  or  not  during 
project  implementation.  These  results  should  be  viewable  by  both  the  PD  and  PM 
staff  for  a  project. 

3.2.8  Requirements  Traceability 

The  last,  and  most  significant,  group  of  deficiencies  in  the  current  process  is  the  complete  lack  of 
traceability  that  exists  for  requirements  and  specifications.  As  a  result  of  a  lack  of  process,  the 
posting  cycle,  and  decreasingly  smaller  office  sizes  within  the  headquarters  the  documentation 
trail  for  projects  is  reported  to  be  less  than  complete. 

As  a  result,  there  is  little  history  behind  the  requirements  on  many  projects,  and  therefore  little 
justification  or  rationale  for  edits.  This  makes  any  current  requirement  set  difficult  to  understand 
at  times,  and  makes  all  requirements  easier  to  edit  (or  too  easy  to  edit). 

This  lack  of  traceability  includes  the  link  between  a  requirement  and  a  specification,  where  one 
requirement  can  develop  into  pages  of  specifications  making  it  very  difficult  to  track  the  link  back 
to  a  requirement. 

3.2.8.1  Process  Requirements 

The  required  changes  to  the  process  in  order  to  establish  requirements  and  specification 
traceability  include: 

1 .  Obtain  Requirements  Management  Software  to  Enter/Edit/Trace  Requirements  and 
Specifications  Through  the  Life  Cycle  (i.e.  SOR-Spec  Maker  Software) 

2.  Ensure  that  Requirements  “Rationale”  is  Tdentified  and  Tracked  Within  the  Software 
Requirements  Database. 

3.  Ensure  that  the  Software  is  Used  by  Both  the  PD  and  PM  staff  to  establish  traceability 
between  requirements  and  specifications. 

3.2.8.2  SOR-Template  Requirements 

There  were  no  SOR  Template  format  requirements  identified  that  related  directly  to 
traceability. 

3.2.8.3  SOR-Spec  Maker  Requirements 

There  are  a  number  of  software  requirements  related  to  traceability,  including  the 
requirements  to  allow  the  user  to: 

a)  Login  as  Author  (only  DLR  alter  Requirements,  only  PM  staff  alter  Specs) 

b)  Enter  Requirements  (max  1  minute  per  entry) 

c)  Record  Rationale 
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d)  “Split”  and  “Merge”  Requirements  as  Necessary  while  maintaining  historical  records 

e)  Number  and  Maintain  Standard  Numbering  of  Requirements  and  Specs 

f)  Identify  Interdependencies  Between  Requirements 

g)  Record  Priority  of  Each  Requirement 

h)  Track  up  to  10,000  to  15,000  Requirements  per  projects,  and  therefore  up  to  100,000 
entries  per  project  including  edits. 

i)  Ability  to  “  Freeze”  a  Version  of  an  SOR  or  a  Spec  for  Distribution  and  Placement  in 
an  On-Line  Library 

j)  Tag  Requirements  Once  Validated  With  Users 

k)  Generate  Standard  Reports  (SOR,  SOR+Rationale,  etc. . . ) 

3.3  Lessons  Learned  on  Past  Projects 

Throughout  the  interviews  with  current  and  past  project  staff  a  number  of  “Lessons  Learned” 
were  identified  related  to  the  SOR  and  Spec  Development  process.  It  is  interesting  to  note  that 
most  of  these  lessons  learned  overlap  with  the  requirements  or  recommendations  for  future 
changes  to  the  process.  This  suggests  that  if  these  changes  are  implemented  systematically  there 
will  be  more  widespread  success  similar  to  the  “  pockets”  of  success  resulting  from  these  lessons. 
The  lessons  learned  identified  included: 

•  Develop  SOR/Spec  as  a  PD/PM  team 

•  Build  context  (i.e.  scenarios)  as  you  go,  if  operational  scenarios  or  other  context 
information  is  not  available. 

•  Monitor  and  be  aware  of  what  current  and  near  future  technology  is  capable  in  order  to 
develop  a  realistic  SOR. 

•  Understand  technical  tests  and  results  and  their  impact  on  requirements 

•  Ask  the  “  experts” ,  use  the  DREs 

•  Start  SOR  development  early  and  iterate  requirements 

•  Finalize  SOR  at  the  last  minute 

•  Develop  operational  scenarios  then  task  analyze 

•  Validate  requirements  with  users  through  focus  groups 

•  Obtain  and  evaluate  prototypes  through  user  trials. 

•  Continue  user  trials  through  detailed  design/development. 

•  Get  independent  sources  to  conduct  focus  groups  and  trials. 

•  Develop  an  SOR  template  and  follow  it 

3.4  Future  Trends 

The  analysis  for  this  study  identified  a  number  of  future  trends  or  initiatives  related  to  the  results 
outlined  in  this  report.  The  primary  future  trend  is  a  movement  toward  Benefit  Driven 
procurement  or  the  Tabular  Format  of  procurement,  and  away  from  historical  Tender-Theory 
models.  These  procurement  strategies  result  in  bid  evaluations  based  more  on  capability  with 
rewards  for  performance  and  ‘gates’  to  track  progress  throughout  development.  These  future 
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changes  appear  to  have  more  of  an  impact  on  the  design  of  the  Spec  and  Subsequent  Tracking  of 
specifications  as  opposed  to  the  requirements  development  process  and  the  design  of  the  SOR. 

In  addition  to  these  future  trends  a  parallel  study  was  identified,  managed  from  the  Directorate  of 
Force  Planning  and  Project  Coordination  (DFPPC)  and  conducted  by  a  consultant  (B.  Lowthian). 
One  component  of  this  work  has  been  the  development  of  proposals  for  new  SOR  formats.  A  draft 
version  of  the  proposed  SOR  format  was  obtain  in  the  final  stages  of  this  study.  The  Lowthian 
proposals  address  many  of  the  recommendations  in  this  report,  including  a  focus  of  requirements 
on  task  performance  requirements,  and  the  analysis  of  1 1  DND  Scenarios. 

There  are  a  number  of  areas  where  the  results  of  this  report  could  be  integrated  as  enhancements  to 
the  Lowthian  SOR  proposals,  including  the  systematic  integration  of  human  factors  issues.  It  is 
highly  desirable  to  meet  with  these  DFPPC  personnel  and  determine  if  the  these  recommendations 
can  be  integrated  into  their  initiatives. 


3.5  Summary  of  Process  Requirements 

Throughout  this  section  a  number  of  requirements  have  been  identified  for  modifications  to  the 

SOR  development  process.  In  summary  these  requirements  included: 

1 .  Develop  a  Process  Bigger  Than  Any  One  Individual. 

A  documented  SOR  development  process  should  be  created  that  introduces  some  key 
milestones  required  in  the  development  of  an  SOR.  This  process  should  be  flexible  enough  to 
accommodate  the  wide  range  of  project  types,  but  formal  enough  that  project  staff  can 
understand  where  each  other  are  in  their  project  sequence.  This  process  should  include 
systematic  analysis  of  requirements,  validation  with  the  user  community,  and  documentation 
of  requirement  rationale,  all  of  which  make  it  difficult  for  any  one  person  to  change  the  track 
of  a  project  without  evidence. 

2.  Define  the  DLR  Requirements  Officer  as  a  Coordinator. 

The  role  of  the  DLR  Requirements  Officer  should  be  officially  defined  as  that  of  a 
coordinator.  This  role  requires  the  officer  to  organize  the  integration  of  a  wide  range  of  user 
and  technical  specialist  input  into  a  requirements  document,  and  does  not  require  the  officer  to 
be  the  sole  knowledge  source  behind  a  system. 

3 .  Create  a  Project  “Team”  From  Day  1 . 

In  the  current  system  a  Project  Implementation  Team  is  created  once  a  project  goes  out  for 
bid.  This  team  identifies  a  number  of  support  personnel  for  a  project  including  requirements, 
training,  doctrine,  fielding,  engineering,  etc..  These  same  roles  should  be  defined  at  SS(ID) 
such  that  the  requirements  coordinator  (the  DLR  officer)  has  identified  personnel  who  will 
expect  him/her  to  call  for  input  during  the  requirements  development  process.  The  team 
members  (in  a  matrix  approach)  will  include  representatives  from  Doctrine/Operational 
Concepts,  User  Tasks  (Ops  &  Maintenance),  Deficiencies/Lessons  Learned,  Requirements, 
Project  Management/Engineering,  Research  Resources  (Personnel/Data/Studies),  Quality 
Assurance,  Public  Works  and  Government  Services  Canada  (PWGSC),  Training,  Staffing,  and 
Deployment.  Many  of  these  personnel  will  only  be  called  upon  to  review  an  SOR  or  provide 
quick  input,  but  input  from  all  of  these  groups  will  increase  the  quality  of  the  requirements  set 
and  prevent  re-work  at  the  last  minute. 
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4.  Develop  Army  Wide  Scenarios/Missions 

The  Canadian  Forces  should  provide  a  series  of  standardized  missions  and  scenarios  that  they 
expect  the  Land  Forces  to  support.  Over  time  the  different  arms  should  analyze  how  they 
would  deploy  to  support  these  scenarios  in  the  future,  with  support  from  the  Directorate  of 
Army  Doctrine  and  Future  Concept  Groups.  This  information  should  be  documented  and 
integrated  into  the  instruction  program  at  the  Kingston  Tech  Staff  School. 

5.  Identify  and  Prioritize  Army  Wide  Requirements 

Based  on  the  Force  wide  scenarios,  a  set  of  deficiencies  should  be  maintained  that  provides  a 
prioritized  list  of  deficiencies  that  DLR  needs  to  address.  This  list  should  then  be  used  as  one 
input  to  guide  the  allocation  of  resources.  This  would  not  only  provide  structure  and  some 
predictability  to  the  requirements  analysis  process,  but  would  also  address  some  of  the 
concerns  discussed  in  Section  3.2.1  related  to  personality  driven  procurement  priorities. 

6.  DND  Provide  DLR  with  Doctrine  and  Future  CONOPS  Support 

DLR  staff  should  be  provided  with  links  to  personnel  in  the  Directorate  of  Arm  Doctrine  and 
the  Future  Concepts  group  at  the  start  of  the  project  SS(ID)  or  prior  to  when  the  SOR  will  be 
developed.  These  personnel  should  provide  guidance  on  where  the  project  fits  in  to  future 
operations  and  how  it  is  likely  to  be  deployed  within  the  standard  force  scenarios. 

7.  Task  Analyze  to  Develop  Requirements 

Once  future  scenarios  and  operational  concepts  are  defined  for  a  project  they  should  be  task 
analyzed  to  determine  the  user  requirements  for  the  future  system.  This  analysis  should  focus 
on  the  “  What?”  aspects  of  future  task  performance  (i.e.  what  the  system  needs  to  do  to 
support  future  task  performance),  and  not  on  the  “  How?” . 

8.  Task  Analyze  to  Develop  Test  Scenarios  and  Measures 

Task  analysis  of  future  scenarios  and  concepts  should  also  be  conducted  to  extract  the 
performance  measures  and  scenario  vignettes  necessary  to  develop  user  centred  product 
acceptance  trials. 

9.  Identify  Links  to  Information  for  Each  Project. 

Provide  the  Requirements  Officer  Links  to  a  range  of  information  sources,  including  Army 
Operations  (Scenarios),  Operational  Concepts,  Doctrine  and  Future  Concepts,  and  Research 
personnel. 

10.  Define  DRE  Role  to  Support  DLR  Projects 

There  is  a  need  to  define  the  role  for  DRE  staff  to  support  DLR  projects  and  to  communicate 
this  in  any  future  descriptions  of  the  SOR  Development  Process.  It  would  appear  that  key 
points  in  this  definition  should  be  that  DREs  must  support  DLR  projects,  but  that  they  may  not 
be  able  to  do  all  the  work  themselves  at  which  point  they  may  be  required  to  act  as  technical 
experts  to  help  select  or  supervise  contract  personnel. 

11.  Train  Scientists  on  the  Development  Process. 

The  Scientific  Authorities  in  the  DREs  should  be  provided  with  training  on  the  System 
Development  cycle  and  the  SOR-Spec  Development  Process.  This  training  should  emphasize 
the  information  “products”  that  DLR  staff  require  and  the  typical  timelines  that  they  are  being 
asked  to  work  within. 


Hummsystems  Incorporated 


SOR-Spec  Maker  Final  Report 


Page  39 


12.  A  SOR  Development  Process  should  be  established,  documented,  and  taught.  This  process 
should  include  key  milestones  that  all  Requirements  Officer  should  pass  through  in  the 
development  of  SOR,  including  Mission/Scenario  Definition,  Function/Task  Analysis, 
Identification  of  Relation  Projects,  Internal  SOR  Review,  Requirements  Validation  with  Units, 
Evaluation  of  Requirements  through  Trials  of  Prototypes  or  Mockups,  etc.. 

13.  Any  formal  SOR  Development  Process  should  include  the  requirement  for  review  with  the 
future  user  community  and  subsequent  requirement  iteration. 

14.  Develop  a  Common  SOR  Format  and  have  all  projects  follow  it.  This  does  not  appear  to  be  an 
unreasonable  requirement  as  all  SORs  analyzed  during  this  project  could  be  reworked  into  a 
common  format. 

15.  Make  all  SOR  Sections  Mandatory,  with  Not  Applicable  or  Not  Available  as  acceptable  inputs 
to  SOR  sections  provided  there  is  a  reasonable  rationale  provided. 

16.  Encourage  the  Requirements  Officer  to  develop  the  full  requirement  for  a  system,  at  least  on 
the  first  few  passes,  to  ensure  that  the  full  range  of  requirement  are  documented  at  least  once 
for  future  reference. 

17.  The  requirements  development  process  needs  to  incorporate  standard  analysis  milestones 
related  to  systematic  analysis  of  user  requirements.  These  milestones  should  include: 

•  The  definition  of  missions  and  scenarios. 

•  The  develop  of  a  Concept  of  Operations  in  terms  of  how  personnel  will  use  the  future 
system  within  the  context  of  the  identified  missions  and  scenarios. 

•  Function  and  task  analysis  of  these  scenarios  to  extract  requirements. 

•  The  completion  of  a  User  Group(s)  at  operational  units  early  in  the  requirements 
development  process  to  validate  the  scenarios,  the  Concept  of  Operations,  and  the 
preliminary  requirements. 

•  The  completion  of  a  User  Trial(s)  later  in  the  requirements  development  process  using 
prototype  products,  storyboards  of  design  concepts,  or  buy  and  try  products. 

•  The  integration  of  Human  Factors  standards  into  the  requirements  development  process. 

•  The  completion  of  User  Trial(s)  during  Project  Implementation  to  validate  detailed  design 
concepts  and  to  provide  the  necessary  data  for  Trade  Off  studies  when  choices  must  be 
made  between  design  alternatives. 

18.  It  would  be  beneficial  if  there  was  a  qualified  human  factors  staff  member  in  Ottawa  to 
support  Land  Force  procurement.  This  officer  would  need  to  be  a  fully  qualified  human 
factors  profession  (according  to  industrial  certification  qualifications),  and  would  be  available 
to  provide  human  factors  support,  link  human  factors  requirements  across  projects,  and  liase 
with  D.C.I.E.M.  on  research  issues. 

19.  Establish  the  Link  Between  the  PD  and  PM  Early  in  the  Process. 

The  few  projects  that  do  this  now  and  really  work  together  appear  to  really  understand  each 
other  better,  and  do  not  appear  to  have  to  revisit  issues  during  implementation. 
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20.  Develop  the  SOR  and  Spec  in  Parallel. 

The  few  projects  who  do  this  appear  to  have  a  strong  relationship  between  the  PD  and  PM 
staff,  with  a  general  understanding  of  the  issues  driving  each  others  documents.  The  DLR 
staff  on  the  PD  side  understand  the  technical  testing  that  the  engineering  staff  will  conduct  and 
the  issues  related  to  the  feasibility  of  delivering  certain  technologies,  while  the  engineering 
staff  on  the  PM  side  develop  a  better  understanding  of  how  the  system  will  be  used  and  what 
the  requirements  mean.  In  these  situations  the  DLR  staff  appear  to  be  able  to  stay  focused  on 
making  their  document  a  statement  of  the  requirement  (the  “  What”  ). 

21.  Conduct  User  Studies  and  Tech  Studies  in  Parallel  to  Validate  Requirements. 

When  the  PD  and  PM  staff  work  together  early  in  the  process  the  development  of  operational 
analysis  or  the  procurement  of  prototype  products  can  meet  both  their  needs.  In  these  cases 
focus  groups  with  users  can  answer  questions  of  interest  to  both  parties,  while  prototype 
products  can  be  tested  in  user  trials  to  validate  requirements  and  then  tested  by  engineering  to 
validate  specifications  and  testing  criteria. 

22.  Track  the  Relationship  Between  Requirements  and  Specifications. 

The  PD  and  PM  staff  should  develop  analysis  that  tracks  the  link  between  requirements  and 
specifications  to  facilitate  assessments  of  the  impact  of  requirement  changes  on  specs  and  the 
impact  of  specification  changes  on  requirements. 

23.  Work  Towards  Best  Value  Bid  Evaluation  Methods. 

The  more  “  Best  Value”  evaluation  methods  can  be  used,  the  more  “  honest”  all  parties  can  be 
about  the  relative  priority  of  requirements  and  specs,  which  will  decrease  the  time  spent  on 
exact  wording  and  rating  while  providing  a  richer  base  or  priorities  to  guide  procurement 
decisions. 

24.  Obtain  Requirements  Management  Software  to  Enter/Edit/Trace  Requirements  and 
Specifications  Through  the  Life  Cycle  (i.e.  SOR-Spec  Maker  Software) 

25.  Ensure  that  Requirements  “Rationale”  is  Identified  and  Tracked  Within  the  Software 
Requirements  Database. 

26.  Ensure  that  the  Software  is  Used  by  Both  the  PD  and  PM  staff  to  establish  traceability 
between  requirements  and  specifications. 


3.6  Summary  of  SOR  Template  Requirements 

Throughout  this  section  a  number  of  requirements  have  been  identified  for  modifications  to  the 
SOR  Template  format.  A  proposed  SOR  Template  has  been  included  as  Annex  A  to  this  report. 

In  summary  the  requirements  for  this  SOR  Template  included: 

1 .  Develop  a  Common  SOR  Format  and  have  all  projects  follow  it. 

2.  Identify  the  Project  Team  Members  on  the  SOR. 

Each  of  the  personnel  identified  to  support  a  project  should  be  listed  on  one  of  the  cover  sheets 
of  the  SOR.  This  formally  recognizes  the  DLR  Officer  as  the  coordinator  with  multiple 
technical  inputs,  and  clearly  identifies  those  expected  to  provide  technical  input. 
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3.  Include  standard  sections  on  Missions/Scenarios,  Operational  Concepts,  and  Key  Tasks  where 
the  Requirements  Officer  can  summarize  the  future  operational  context  for  the  system. 

4.  Ensure  that  all  SOR  section  titles  in  the  template  are  mandatory,  with  “Not  Applicable”  or 
“Not  Available”  being  acceptable  input  with  an  associated  rationale.  This  will  help  ensure 
that  these  issues  are  addressed,  if  not  in  the  initial  development  of  an  SOR,  then  through  the 
review  process. 

5.  The  SOR  Template  should  contain  a  Required  Section  that  Identifies  Related  Projects 

6.  To  support  the  systematic  analysis  of  user  requirement,  include  the  following  mandatory 
sections: 

a)  Related  Projects.  This  section  placed  early  in  the  document  identifies  the  other  ongoing 
projects  that  should  be  considered  to  ensure  that  the  future  user  will  have  an  integrated 
system  to  support  overall  mission  and  task  performance. 

b)  Missions,  and  Scenarios.  These  sections  outline,  at  least  at  a  high  level,  the  types  of 
operations  the  new  system  or  product  must  support.  These  descriptions  must  form  the 
basis  of  task  analysis  activities  to  extract  requirements,  and  the  basis  of  user  trial  design  to 
evaluate  concepts  with  future  users. 

c)  Concept  of  Operations.  This  section  outlines  how  the  future  system  will  be  used  within 
the  context  of  the  missions,  scenarios,  and  tasks.  This  information  outlines  how  future 
equipment  is  likely  to  operate,  how  it  will  be  staffed,  how  information  will  flow  (in  the 
case  of  information  systems,  and  the  major  soldier-machine  interfaces  that  will  be 
required  to  operate  the  system. 

d)  Key  Tasks.  This  sections  outlines  the  key  tasks  to  be  performed  at  each  of  the  major 
soldier-machine  interfaces,  when  using  the  system  in  support  of  the  future  concept  of 
operations,  within  the  design  basis  mission  and  scenarios.  These  critical  tasks  should  be 
the  focus  of  task  analysis,  and  user  trials  must  replicate  these  tasks  to  evaluate  system 
performance  with  humans  in  the  loop. 

e)  Concept  of  Support.  This  section  outlines  the  organization  of  the  support  structure  to 
maintain  the  system,  the  major  support  positions  that  are  likely  to  be  required,  and 
identifies  the  key  maintenance  support  tasks. 

f)  User  Characteristics.  This  section  identifies  and  describes  the  key  characteristics  of  the 
full  range  of  potential  operators  and  maintained.  Example  user  characteristics  include 
age,  sex,  language,  education,  training,  size,  handedness,  sensory  capabilities  (eg:  sight, 
colour  vision,  hearing),  or  the  amount  and  type  of  operational  experience.  References  for 
these  characteristics  should  be  used  wherever  possible  (eg:  description  of  training  levels  or 
courses,  Canadian  Forces  Anthropometric  studies,  or  selection  criteria).  The  range  of  the 
population  in  each  category  should  also  be  defined,  with  the  expected  design  goal  being  to 
accommodate  95%  of  the  future  user  population  through  the  acquisition  of  the  new  system 
and  the  training  to  accompany  it.  In  some  systems  ,with  small  numbers  of  pre-selected 
specialized  users  (eg:  pilots,  navigators,  divers),  the  system  should  accommodate  100%  of 
the  user  population 


Page  42 


SOR-Spec  Maker  Final  Report 


Humanyvjfeffj.v  Incnmoratpri 


g)  Human  Factors  Performance  Requirements.  Within  each  set  of  requirements  at  the  system 

or  sub-system  level  there  are  four  categories  of  requirements  that  must  be  identified: 

•  Soldier  /  Crew  Task  Performance.  These  requirements  outline  the  key  task 
performance  characteristics  for  the  system  or  sub-system.  These  requirements 
describe  key  task  elements  that  the  future  user  must  be  able  to  complete,  and  describe 
the  speed,  accuracy,  and  usability  criteria  that  must  be  met  to  achieve  adequate  system 
performance  within  the  future  concept  of  operations. 

•  Soldier-Machine  Interface  /  Crew  Station.  These  requirement  outline  the  key 
equipment  interfaces  that  must  be  included  to  support  each  of  the  system  or  sub¬ 
systems.  It  will  also  identify  any  critical  layout  requirements  related  to  equipment 
access,  the  range  of  the  population  that  must  be  accommodated  according  to  a  number 
of  parameters,  or  compartment  access  and  egress. 

•  System  Safety  /  Health  Hazards.  These  requirements  will  describe  the  features  that 
the  future  system  requires  to  ensure  the  safety  of  the  future  users. 

•  User  Acceptance.  These  requirements  describe  the  requirements  of  the  future  system 
to  ensure  user  acceptance,  and  details  any  future  user  testing  requirements  to  evaluate 
performance,  ease  of  use,  and  utility  of  proposed  designs. 

h)  Personnel  and  Training.  These  requirements  relate  the  number  of  personnel  required  to 
operate  the  system,  the  characteristics,  skills,  and  experience  of  available  personnel,  and 
the  details  of  the  training  systems  and  programs  that  will  be  required  to  develop  skill  in 
these  future  users. 


3.7  Summary  of  SOR-Spec  Maker  Requirements 

Throughout  this  section  a  number  of  requirements  have  been  identified  for  procurement  of 

requirements  management  software.  These  SOR-Spec  Maker  software  requirements  are  detailed 

further  in  a  Statement  of  Operational  Requirements  in  Annex  B  to  this  report.  However,  in 

summary  the  high  level  SOR-Spec  Maker  requirements  include: 

1 .  Provide  a  template  to  identify  all  key  project  support  personnel,  with  contact  information  for 
each,  including  a  direct  e-mail  link. 

2.  Provide  an  SOR  Development  Process  “  Wizard”  that  provides  the  outline  of  the  key  steps 
requirement  and  the  ability  for  the  Requirements  Officer  to  indicate  where  they  are  in  the 
process. 

3.  Provide  an  SOR  Template  Based  on  the  New  Common  SOR  Format. 

4.  Ensure  that  all  section  titles  are  mandatory,  requiring  the  writer  to  fill  in  some  content  or  state 
“Not  Applicable”  or  “Not  Available”  with  rationale. 

5.  Provide  Dynamic  To-Do  Lists  for  the  Major  Milestones  and  Analysis  Required. 

6.  Provide  Context  Specific  Help  with  Pointers  to  DND  Support  Agencies  for  each  of  the  major 
milestones  that  should  be  covered  in  the  development  of  the  SOR. 

7.  Provide  On-Line  “Help”  on  SOR  Section  Contents. 

SOR-Spec  Maker  Final  Report 


Humansyste/ns  Incorporated 


Page  43 


8.  Provide  On-Line  “Pointers”  to  Resources  within  DND  that  could  assist  in  the  Completion  of 
SOR  Sections. 

9.  Provide  pointers  to  human  factors  support  agencies  (eg:DCIEM)  within  the  help  system  for 
the  product  in  relation  to  those  SOR  sections  related  to  human  factors  issues. 

10.  Contain  a  Missions/Scenario  section  that  provides  a  link  to  a  summary  of  the  Land  Force 
scenarios  that  system  must  support.  The  software  should  allow  this  scenario  text  to  be  placed 
in  the  Mission/Scenario  section  of  the  SOR  or  in  an  Annex  depending  on  how  much  additional 
data  the  Requirements  Officer  has  to  incorporate  with  it. 

1 1 .  Provide  links  to  Soldiers  Day  and  any  other  task  description  tools  available  to  support 
systematic  analysis  of  user  missions,  scenarios,  and  tasks. 

12.  Provide  software  links  to  as  many  information  sources  as  possible  from  one  common 
Information  Link  tool.  The  data  required  by  DLR  officers  is  increasingly  being  produced  in 
electronic  form,  which  increase  the  future  utility  of  a  software  based  link  to  information. 

These  links  my  be  based  on  data  available  on  CD-ROMs  or  over  Intranet  sites.  A  role  should 
be  defined  within  DLR  Coordination  to  monitor  electronic  information  sources  and 
continually  update  these  links  for  the  project  teams.  Example  links  for  this  tool  include: 

•  Doctrine  (Electronic  Battle  Box  CD,  Others...) 

•  Task  Data  from  Soldiers  Day,  or  Other  DND  Documents 

•  Literature  (Research,  Studies) 

•  Past  SORs,  Related  SORs 

•  Design  Standards,  Test  Methods,  Test  Criteria 

•  Lessons  Learned  CD-ROMs  or  Databases 

•  Deficiencies  in  Existing  Systems  (eg:  The  Army  Combat  Clothing  and  Equipment 
Survey  System  (ACCESS),  or  UCRs) 

•  The  Defence  Research  Establishments 

13.  Develop  an  SOR-Spec  Library. 

Each  time  an  SOR  or  Spec  is  ‘frozen’  as  a  version  for  distribution  and  comment  the  SOR-Spec 
Maker  software  should  provide  a  facility  to  deposit  the  version  into  a  library.  The  version 
deposited  in  the  library  should  overwrite  the  last  version  that  was  placed  there.  The  most 
recent  version  of  an  SOR  or  Spec  should  remain  in  the  library  for  10  years  unless  it  is 
overwritten  by  a  more  recent  one.  The  library  should  contain  a  search  engine  and  the  ability  to 
copy  requirements  from  a  located  document  into  the  current  SOR  or  Spec  under  development. 

14.  Allow  the  DLR  staff  and  the  engineers  to  develop  the  requirements  and  specifications  for  a 
project  in  parallel. 

15.  Allow  the  DLR  staff  to  view  but  not  edit  specifications,  and  allow  the  engineers  to  view  but 
not  edit  the  requirements. 

16.  Provide  the  PM  staff  with  a  process  wizard  and  information  links  related  to  the  specification 
development  process.  Information  links  should  include  many  of  the  same  resources  available 
to  DLR  staff  in  addition  to  technical  standards  (Defence  and  Industrial). 

17.  There  are  a  number  of  software  requirements  related  to  traceability,  including  the 
requirements  to  allow  the  user  to: 
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a)  Login  as  Author  (only  DLR  alter  Requirements,  only  PM  staff  alter  Specs) 

b)  Enter  Requirements  (max  1  minute  per  entry) 

c)  Record  Rationale 

d)  “  Split”  and  “  Merge”  Requirements  as  Necessary 

e)  Number  and  Maintain  Standard  Numbering  of  Requirements  and  Specs 

f)  Identity  Interdependencies  Between  Requirements 

g)  Record  Priority  of  Each  Requirement 

h)  Track  up  to  10,000  to  15,000  Requirements  per  projects,  and  therefore  up  to  100,000 
entries  per  project  including  edits. 

i)  Ability  to  “  Freeze”  a  Version  of  an  SOR  or  a  Spec  for  Distribution  and  Placement  in 
an  On-Line  Library 

j)  Tag  Requirements  Once  Validated  With  Users 

k)  Generate  Standard  Reports  (SOR,  SOR+Rationale,  etc. ..) 

18.  Allow  the  user  to  describe  how  specifications  will  be  tested,  develop  summaries  of 

specification  tests,  and  track  whether  specifications  are  passing  tests  or  not  during  project 
implementation.  These  results  should  be  viewable  by  both  the  PD  and  PM  staff  for  a  project. 

3.8  Review  of  Candidate  Software  Tools 

Throughout  this  study  a  number  of  software  products  were  reviewed  for  their  potential  integration 
into  the  requirements  management  process.  The  ReqMan  and  RT  Expert  products  were  quickly 
reviewed  for  their  potential  as  requirements  management  tools,  while  the  Soldier  Day  and  HFE 
Guide  applications  were  briefly  reviewed  for  potential  links  to  the  requirements  management 
process. 

3.8.1  ReqMan 

ReqMan  is  a  requirements  management  tool  under  development  at  the  Defence  Resereach 
Establishment  Valcartier  (DREV).  At  the  time  of  review  it  was  a  prototype  product. 

ReqMan  provides  the  user  with  a  graphical  user  interface  to  a  requirements  database  and  the 
capabilities  to  enter,  edit,  merge,  split,  and  number  requirements.  Standard  reports  can  be 
generated  using  these  data. 

ReqMan  was  the  easier  to  use  of  the  products  reviewed,  but  had  extremely  low  performance  (eg: 

1 0  minutes  to  enter  a  requirement  where  500+  entries  were  in  the  database).  ReqMan  also  lacked 
some  key  features  required  by  users,  as  identified  in  this  study,  such  as  interdependency  tracking 
and  tools  to  support  interdependency  analysis. 

ReqMan  would  not  be  suitable  for  widespread  use  within  DLR  until  further  development  was 
completed  to  extend  its  functionality. 
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3.8.2  RT  Expert 

RT  Expert  is  a  commercial  requirements  management  application  available  through  a  developer  in 
the  Montreal  area.  It  is  a  polished  software  product  available  for  sale. 

RT  Expert  is  more  difficult  to  use  than  ReqMan  as  the  interface  is  more  complex,  and  the  user 
must  develop  an  understanding  of  the  “structure”  of  the  requirements  managed  with  RT  Expert. 
This  requires  the  user  to  identify  static  and  dynamic  requirements,  and  input  and  output 
requirements,  among  others.  As  a  result  RT  Expert  has  a  very  steep  learning  curve  and  is  likely 
not  suitable  in  its  current  form  for  use  throughout  DLR,  as  users  would  be  unlikely  to  enter  their 
requirements  into  the  software  (which  is  the  most  critical  aspect  of  SOR-Spec  Maker). 

However,  once  requirements  are  entered  correctly  into  RT  Expert  it  appears  to  provide  powerful 
tools  for  tracking  and  visualizing  requirements  interdependencies,  and  recording  the  status  of 
requirements  and  specification  in  terms  of  testing  results. 

In  summary  RT  Expert  has  the  tools  more  suited  for  the  engineering  side  of  the  procurement 
process,  but  lacks  a  simple  interface  for  the  user  to  enter  and  edit  requirements,  and  then  later 
establish  interdependencies  between  them.  As  a  result  it  is  not  suitable  for  wide  spread  use  across 
DLR  at  this  time. 

3.8.3  ReqMan  vs  RT  Expert 

A  comparison  between  ReqMan  vs  RT  Expert  indicates  that  they  each  provide  a  general  coverage 
of  equal  proportions  of  the  SOR-Spec  Maker  requirement,  but  in  different  areas,  while  RT  Expert 
provides  an  additional  suite  of  capabilities  for  which  no  requirement  has  been  identified  to  date. 
This  relationship  is  illustrated  in  Figure  7. 


Figure  7:  ReqMan  and  RT  Expert  Compared  to  SOR-Spec  Maker  Requirements 

3.8.4  LFCS  Requirements  Management  Tool 

During  the  analysis  for  this  project  it  was  discovered  that  the  PD  and  PM  staff  for  the  Land  Force 
Command  System  (LFCS)  project  have  developed  a  Windows  based  tool  to  enter,  edit,  split, 
merge,  and  track  the  interdependencies  of  requirements,  while  maintaining  numbering  and 
generating  standard  SOR  and  Spec  reports.  This  tool  “  grew  up”  as  necessary  during  the  evolution 
of  the  project  and  now  tracks  the  history  of  a  10,000+  requirements  database  with  associated 
specifications. 
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While  this  product  was  not  fully  investigated  during  the  analysis  it  appears  to  offer  the  core 
features  for  requirements  management  and  should  be  given  further  review. 

3.8.5  Soldiers  Day 

Soldiers  Day  is  a  CD-ROM  based  Windows  application  developed  by  D.C.I.E.M.  to  provide  a 
multi-media  record  of  the  key  missions,  tasks,  and  equipment  related  to  dismounted  infantry 
operations.  This  product  may  in  the  future  include  mounted  infantry  operations,  from  the 
perspective  of  equipment  compatibility. 

Soldiers  Day  primarily  supports  the  needs  of  DLR  5  personnel,  but  is  likely  to  have  some  utility 
for  other  branches  as  well.  The  product  “  shell”  is  suitable  for  housing  task  and  equipment  based 
data  on  any  form  of  military  activity,  and  when  populated  provides  a  very  rich  data  resource  to 
guide  requirements  development  and  design.  Soldier’s  Day  includes  a  search  engine  that 
facilitates  the  rapid  location  of  information  related  to  entered  keywords. 

Soldiers  Day  should  be  linked  to  SOR-Spec  Maker  through  the  Information  Links  component  of 
the  product,  whereby  the  SOR-Spec  Maker  user  could  click  on  an  “  icon”  to  access  Soldiers  Day 
over  a  network  or  over  the  Intranet  and  search  for  information  related  to  their  project.  It  should 
also  be  considered  by  other  branches  of  DLR  as  a  candidate  to  hold  task  and  equipment  data  to  be 
used  as  a  basis  for  requirements  analysis  and  design. 

3.8.6  HFE  Guide 

HFE  Guide  is  a  Macintosh  based  software  application  that  must  be  installed  on  the  users 
computer.  The  product  is  currently  in  a  prototype  form,  but  is  used  by  some  human  factors 
personnel  through  the  Canadian  Forces. 

HFE  Guide  provides  human  factors  design  guidance  in  a  number  of  different  areas,  including: 

•  Human  Factors  Design  Guidelines  (Mil  Std  1472D) 

•  Aircraft  Design  Standards  (STANAG  and  ASCC) 

•  Generic  Task  Analysis  Information 

•  Human  Factors  Methods 

•  Human  Factors  Process  (Mil  Std  46855) 

•  User  Test  Methods 

In  general,  HFE  Guide  provides  quick  access  to  military  standards  for  basic  human  factors 
analysis  processes  and  design  guidelines,  and  therefore  has  the  potential  for  a  useful  resource 
during  the  requirements  analysis.  This  utility  is  likely  to  increase  as  Requirements  Officers 
continue  to  become  more  familiar  with  human  factors  issues  and  methods. 

It  would  be  useful  to  link  HFE  Guide  to  SOR-Spec  Maker  software  as  a  human  factors  guideline 
and  process  resource  link.  To  accomplish  this,  it  would  appear  that  HFE  Guide  must  be  converted 
to  a  PC  or  Intranet  format.  Plans  to  complete  this  transition  are  documented  at  D.C.I.E.M  and 
should  be  considered  for  implementation  once  the  final  format  the  requirements  management  core 
of  SOR-Spec  Maker  is  known. 
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4  Recommendations 


This  section  outlines  a  series  of  recommendations  to  guide  future  work  on  the  SOR-Spec  Maker 

Project.  These  recommendations  include: 

1 .  A  small  number  of  DLR  personnel  have  indicated  the  desire  to  obtain  a  Requirements 
Management  software  tool  immediately.  The  two  tools  reviewed  for  this  project  (ReqMan  and 
RT  Expert)  are  not  suitable  in  their  current  form,  as  discussed  in  Section  3.8.  Therefore,  if  it  is 
essential  to  obtain  a  requirements  management  tool  immediately  it  is  recommended  that  the 
tool  in  use  by  the  LFCS  project  be  reviewed  further  and  obtained  by  those  projects  interested. 
However,  further  analysis  is  recommended  prior  to  deploying  a  system  across  DLR  as  outlined 
below. 

2.  To  further  this  study  and  implement  the  requirements  described  throughout  Section  3 .0  the 
following  activities  are  recommended: 

•  Refine  a  Process  for  SOR  Development  and  Finalize  an  SOR  Template,  working  with  the 
DFPPC  initiatives  in  this  area  and  incorporating  the  need  for  user  centred  requirements 
development  as  described  in  this  report. 

•  Conduct  a  review  of  the  Requirements  Management  Tools  available  as  Commercial  Off 
The  Shelf  (COTS)  products.  This  activity  is  likely  to  review  a  number  of  products 
available  through  commercial  software  vendors  but  may  also  involve  the  posting  of  a 
Request  for  Information  (RFI)  on  the  government  procurement  bulletin  boards. 

•  Using  the  information  obtained  from  the  wider  review  of  available  software  tools,  and  the 
information  in  this  report,  conduct  a  Focus  Group  with  future  users  from  DLR  and 
ADM(Mat)  who  will  use  the  SOR-Spec  Maker  tool.  This  Focus  Group  should  review  the 
proposed  changes  to  the  process  and  the  features  of  the  potential  software  tools,  with  the 
goal  of  providing  feedback  to  process  developers  and  focusing  in  on  one  software  product 
for  pilot  testing. 

•  Procure  a  software  tool  and  pilot  test  it  on  an  example  project.  This  is  likely  to  require 
support  from  a  contractor  to  input  and  work  through  the  requirements  management 
process  in  parallel  to  the  actual  project  team  continuing  with  their  work. 

•  Conduct  a  part  task  user  trial  based  on  the  example  project  data.  This  trial  should  involve 
users  interacting  with  the  software  to  complete  task  elements  common  to  the  requirements 
management  process. 

It  is  important  to  note  that  one  software  product  may  not  be  the  best  solution  to  meet  all 
SOR-Spec  Maker  requirements,  and  that  a  COTS  product  may  be  best  for  the  requirements 
management  portion,  while  Intranet  tools  with  databases  and  search  engines  are  better 
suited for  the  Information  Links  features  and  the  Process  Wizard features.  If  this  proves 
to  be  true  an  example  product  should  be  procured  and  evaluated  for  requirements 
management,  while  a  design  for  the  Intranet  product  concepts  is  developed  as 
“storyboards  ”  for  use  in  the  user  review  process. 
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•  Based  on  the  results  of  the  Focus  Group,  the  Example  Project,  and  the  Part  Task  User 
Trial  the  final  set  of  SOR  Spec  Maker  Requirement  should  be  developed  and  used  as  the 
basis  of  procurement  or  development  of  a  final  SOR-Spec  Maker  software  tool. 

•  Once  a  tool  is  procured  the  data  from  the  Example  Project  and  the  modified  Process 
should  be  integrated  into  a  Training  Package  to  be  used  for  informal  immediate  training  at 
NDHQ  and  to  be  passed  to  the  Tech  Staff  School  in  Kingston  for  Future  Use. 

3.  Throughout  the  interviews  for  this  project,  several  officers  indicated  that  they  are  increasingly 
aware  of  the  role  of  human  factors  in  the  development  cycle,  and  those  who  have 
experimented  with  human  factors  integration  preach  the  benefit  in  terms  of  the  resulting 
design  quality.  However,  these  same  personnel  also  indicate  that  understanding  how  to 
integrate  human  factors  analysis  into  the  develop  of  requirements  and  specifications  remains 
one  of  their  greater  challenges.  One  of  the  larger  challenges  is  understanding  how  to  link 
systematic  analysis  of  operational  scenarios  to  the  development  of  requirements  and  interface 
design  concepts.  It  is  therefore  recommended  that  a  Human  Factors  Guidance  Module  be 
developed,  extracting  “  cases”  from  recent  projects  that  have  more  extensive  human  factors 
programs  to  demonstrate  the  link  between  analysis  (Operational  Scenarios,  Function  Analysis, 
Task  Analysis,  User  Reviews)  and  design  (Requirements  and  Specification  Development, 
Interface  Design,  Measures  for  Performance  testing).  Current  Advanced  Development  Model 
(ADM)  projects  (eg:  the  Advanced  Land  Fire  Control  System  (ALFCS)  and  Integrated 
Protective  Clothing  and  Equipment  (IPCE))  would  be  good  candidates  to  extract  sample 
human  factors  analysis  cases,  as  would  some  ongoing  matrix  projects  within  DLR  (Helmet, 
Clothe  the  Soldier,  Leopard  Thermal  Sight,  and  TBCS). 

4.  Once  the  SOR-Spec  Software  is  deployed  and  being  used  by  several  projects,  efforts  should  be 
made  to  regularly  extract  the  human  factors  related  design  requirements  and  specification 
from  SORs  and  Specs.  This  activity  should  be  co-ordinated  through  a  central  human  factors 
group  within  DND  to  generate  Canadian  human  factors  specifications  for  use  on  military 
projects,  and  to  help  identify  areas  where  R&D  activities  are  likely  required. 

5.  A  number  of  the  “  requirements”  for  process  changes  identified  in  Section  3  should  be 
reviewed  as  recommendations  for  change  within  the  operation  of  the  Land  Force  procurement 
process,  including: 

•  The  need  for  Land  Force  operational  scenarios  to  guide  analysis. 

•  The  need  for  prioritized  Land  Force  deficiencies  to  guide  the  management  of  DLR 
projects. 

•  The  need  for  Ottawa  based  Land  Force  human  factors  support  (qualified  as  per  the 
established  commercial  human  factors  certification  agencies)  to  provide  ongoing  guidance 
to  project  teams  and  liaison  with  D.C.I.E.M.. 

•  Educate  scientific  authorities  on  the  System  Development  process,  the  “  products”  needed 
by  project  personnel  to  support  procurement  decisions,  and  the  timelines  that  these 
projects  must  attempt  to  adhere  to. 
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Scope  of  the  SOR  Template  and  the  Need  for  Future  Analysis 

Throughout  this  report  a  number  of  requirements  for  a  future  SOR  Template  have  been  identified. 
These  requirements  fall  primarily  into  the  category  of  human  factors,  and  the  systematic  analysis 
of  user  requirement  within  the  context  of  operational  scenarios. 

This  annex  illustrates  a  proposed  SOR  Template  that  incorporates  these  human  factors  sections. 
An  effort  has  been  made  to  integrate  these  sections  within  the  framework  of  exiting  draft  SOR 
formats.  This  format  requires  the  user  to  document  requirements  in  a  top  down  fashion, 
presumably  in  the  order  that  issues  are  analyzed  (from  missions,  to  tasks,  to  requirements,  etc.). 

No  effort  has  been  made  to  integrate  these  sections  with  the  proposed  frameworks  resulting  from 
recent  DFPPC  studies  as  these  formats  are  still  under  review  and  discussion.  These  results  and  the 
DFPPC  studies  should  be  integrated  through  combined  analysis  and  discussion  in  the  future  to 
produce  a  final  SOR  Template  that  blends  the  results  of  both  studies  wherever  possible. 
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Statement  of  Operational  Requirement 

1.  INTRODUCTION 

1.1.  GENERAL 

This  section  identifies  and  introduces  the  project. 

1.2.  AIM 

This  sections  describes  the  aim  of  the  project. 

1.3.  BACKGROUND 

This  section  summarizes  background  analysis  that  has  led  up  to  the  creation  of 
the  SOR. 

1.4.  CAPABILITY  DEFICIENCIES 

This  section  describes  the  capability  deficiencies  that  form  the  basis  of  the 
project. 

1.5.  PROJECT  LIMITATIONS  AND  CONSTRAINTS 

This  section  outlines  any  identified  limitations  or  constraints  that  bind  the  scope 
or  timeline  of  the  project. 

1.6.  RELATED  PROJECTS 

This  section  identifies  any  other  ongoing  projects  that  should  be  considered  to 
ensure  that  the  future  user  will  have  an  integrated  system  to  support  overall 
mission  and  task  performance. 

2.  MISSIONS,  CONCEPT  OF  OPERATIONS,  AND  TASKS 

2.1.  MISSIONS  AND  SCENARIOS 

This  section  summarizes  the  types  of  operations  the  new  system  or  product  must 
support.  These  descriptions  must  form  the  basis  of  task  analysis  activities  to 
extract  requirements,  and  the  basis  of  user  trial  design  to  evaluate  concepts  with 
future  users. 

2.2.  CONCEPT  OF  OPERATIONS 

This  section  outlines  how  the  future  system  will  be  used  within  the  context  of 
the  missions,  scenarios,  and  tasks.  This  information  outlines  how  future 
equipment  is  likely  to  operate,  how  it  will  be  staffed,  how  information  will  flow 
(in  the  case  of  information  systems),  and  the  major  soldier-machine  interfaces 
that  will  be  required  to  operate  the  system. 
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2.3.  KEY  TASKS 

This  section  outlines  they  key  tasks  to  be  performed  at  each  of  the  major  soldier- 
machine  interfaces,  when  using  the  system  in  support  of  the  future  concept  of 
operations,  within  the  mission  and  scenarios  it  will  have  to  support.  These 
critical  tasks  must  the  focus  of  further  task  analysis,  and  be  replicated  during 
user  trials  conducted  to  evaluate  system  performance  with  humans  in  the  loop. 

2.4.  CONCEPT  OF  SUPPORT 

This  section  outlines  the  organization  of  the  support  structure  to  maintain  the 
system,  the  major  support  positions  that  are  likely  to  be  required,  and  identifies 
the  key  support  tasks. 

2.5.  USER  CHARACTERISTICS. 

This  section  describes  the  key  characteristics  of  the  full  range  of  operators  and 
maintained.  Example  user  characteristics  include  age,  sex,  language,  education, 
training,  size,  handedness,  sensory  capabilities  (eg:  sight,  colour  vision,  hearing), 
or  the  amount  and  type  of  operational  experience.  References  for  these 
characteristics  should  be  used  wherever  possible  (eg:  description  of  training 
levels  or  courses,  Canadian  Forces  Anthropometric  studies,  or  selection  criteria). 
The  range  of  the  population  in  each  category  should  also  be  defined,  with  the 
expected  design  goal  being  to  accommodate  95%  of  the  future  user  population 
through  the  acquisition  of  the  new  system  and  the  training  to  accompany  it.  In 
some  systems  ,with  small  numbers  of  pre-selected  specialized  users  (eg:  pilots, 
navigators,  divers),  the  system  should  accommodate  100%  of  the  user 
population 

3.  OPERATIONAL  ENVIRONMENT 

3.1.  GENERAL 

This  section  describes  the  range  of  operating  conditions  that  the  system  must 
operate  under  when  supporting  the  missions  and  task  described  in  Section  2. 

3.2.  THREATS  AND  THREAT  PRIORITIES 

This  section  outline  the  key  threats,  and  any  known  performance  characteristics 
of  these  threats,  based  on  the  operational  scenarios  and  operating  environments 
identified. 

4.  OPERATIONAL  REQUIREMENTS 
4.1.  GENERAL 

This  section  describes  any  requirements  that  apply  across  the  entire  system. 
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4.2.  DESIGN  AND  CONCEPT  GUIDANCE 

This  section  provides  any  design  or  concept  guidance  that  the  Requirements 
Officer  feels  is  necessary  to  express  the  intent  of  the  SOR,  without  focusing  a 
particular  product  or  solution. 

4.3.  SYSTEM  REQUIREMENTS 

This  section  details  the  system  level  requirements  related  to  the  overall  features 
the  system  must  provide. 

4.3.1.  Performance  Capability 

This  section  details  any  system  level  requirements  related  to  overall  system 
performance,  not  related  to  human  performance. 

4.3.2.  Human  Factors  Requirements 

This  section  details  outlines  the  requirements  related  to  human  operation  of  the 
system,  broken  down  into  at  least  the  following  mandatory  subsections: 

4.3.2.1.Soldier  / Crew  Task  Performance. 

These  requirements  outline  the  key  task  performance  characteristics  for 
the  system.  These  requirements  describe  key  task  elements  that  the 
future  user  must  be  able  to  complete,  and  describe  the  speed  and 
accuracy,  criteria  that  must  be  met  to  achieve  adequate  system 
performance  within  the  future  concept  of  operations. 

4.3.2.2.Soldier-Machine  Interface  /  Crew  Station. 

These  requirement  outline  the  key  equipment  interfaces  that  must  be 
included  to  support  the  system.  It  will  also  identify  any  critical  layout 
requirements  related  to  equipment  access,  the  range  of  the  population 
that  must  be  accommodated  according  to  a  number  of  parameters 
including  environmental  clothing,  or  compartment  access  and  egress. 

4.3.2.3.System  Safety  /Health  Hazards. 

These  requirements  will  describe  the  features  that  the  future  system 
requires  to  ensure  the  safety  of  the  future  users. 

4.3.2.4.  User  Acceptance. 

These  requirements  describe  the  requirements  of  the  future  system  to 
ensure  user  acceptance,  and  details  any  future  user  testing  requirements 
to  evaluate  performance,  ease  of  use,  and  utility  of  proposed  designs. 

4.3.3.  Quantity 

This  section  summarizes  the  number  of  units  that  will  be  required. 
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4.3.4.  Quality 

This  section  details  any  quality  requirements. 

4.3.5.  Location 

This  section  lists  where  the  units  will  be  distributed  about  the  forces. 

SUB  -  SYSTEM  REQUIREMENTS 

This  section  is  repeated  for  each  major  sub-system  that  must  be  specified.  The 
section  details  the  sub-system  level  requirements  related  to  the  features  the 
specific  sub-system  must  provide. 

4.4.1.  Performance  Capability 

This  section  details  any  system  level  requirements  related  to  overall  system 
performance,  not  related  to  human  performance. 

4.4.2.  Human  Factors  Requirements 

This  section  details  outlines  the  requirements  related  to  human  operation  of  the 
sub-system,  broken  down  into  at  least  the  following  mandatory  subsections: 

4.4.2.1.Soldier  /  Crew  Task  Performance. 

These  requirements  outline  the  key  task  performance  characteristics  for 
the  sub-system.  These  requirements  describe  key  task  elements  that  the 
future  user  must  be  able  to  complete,  and  describe  the  speed,  accuracy, 
and  usability  criteria  that  must  be  met  to  achieve  adequate  system 
performance  within  the  future  concept  of  operations. 

4.4.2.2.Soldier-Machine  Interface  / Crew  Station. 

These  requirement  outline  the  key  equipment  interfaces  that  must  be 
included  to  support  each  of  the  sub-systems.  It  will  also  identify  any 
critical  layout  requirements  related  to  equipment  access,  the  range  of  the 
population  that  must  be  accommodated  according  to  a  number  of 
parameters,  or  compartment  access  and  egress. 

4.4.2.3. System  Safety  / Health  Hazards. 

These  requirements  will  describe  the  features  that  the  sub-system 
requires  to  ensure  the  safety  of  the  future  users. 

4.4.2.4.  User  Acceptance. 

These  requirements  describe  the  requirements  of  the  sub-system  to 
ensure  user  acceptance,  and  details  any  future  user  testing  requirements 
to  evaluate  performance,  ease  of  user,  and  utility  of  proposed  designs. 
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4.4.3.  Quantity 

This  section  summarizes  the  number  of  units  that  will  be  required. 

4.4.4.  Quality 

This  section  details  any  quality  requirements. 

4.4.5.  Location 

This  section  lists  how  the  total  number  of  units  will  be  distributed  about  the 
forces. 

5.  TOTAL  SUPPORT  REQUIREMENTS 

5.1.  SUPPORT  REQUIREMENTS 

This  section  outlines  the  method  to  be  used  to  support  and  maintain  the  system. 

5.2.  PERSONNEL  AND  TRAINING 

This  section  outlines  the  requirements  related  to  the  number  of  personnel 
required  to  operate  the  system,  the  characteristics  required  of  those  personnel, 
and  the  details  of  the  training  systems  and  programs  that  will  be  required  to 
develop  skill  in  these  future  users. 

6.  SCHEDULING  REQUIREMENTS 

6.1.  CRITICAL  MILESTONES 

This  section  outlines  the  critical  milestones  and  timings  for  the  project  up  to  and 
including  fielding. 

6.2.  SYSTEM  SERVICE  LIFE  EXPECTANCY 

This  section  details  the  life  expectancy  for  the  system  once  fielded. 

7.  REQUIREMENTS  TABLE 

This  section  summaries  all  the  requirements  identified  throughout  the  document. 

8.  GLOSSARY 

This  section  defines  key  terms  used  throughout  the  document. 
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SOR-SPEC  MAKER 
Statement  of  Operational  Requirement 


1  INTRODUCTION 

1.1  General 

1.1.1  A  recent  study  of  the  development  of  Statement  of  Operational  Requirements  (SORs)  by 
Requirements  Officers  (ROs)  in  the  Directorate  of  Land  Requirements  (DLR)  identified  a 
number  of  deficiencies  in  the  ROs  ability  to  develop  and  track  requirements  for  new 
systems.  One  of  the  recommendations  to  address  these  deficiencies  was  the  procurement 
of  a  software  tool  to  support  the  requirements  management  process.  This  software  has 
been  labeled  the  SOR-Spec  Maker  Software. 

1.2  Aim 

1 .2. 1  This  SOR  defines  the  requirements  for  the  SOR-Spec  Maker  software  tool. 

1.3  Background 

1.3.1  A  study  of  the  SOR  and  Performance  Specification  development  process  was  conducted 
by  the  Defence  and  Civil  Institute  of  Environmental  Medicine  (D.C.I.E.M)  during  the 
winter  of  1998.  This  investigation  reviewed  the  requirements  and  specification 
development  process  through  a  series  of  interviews  and  sample  SOR  reviews. 

1 .3.2  Sources  of  information  in  this  D.C.I.E.M.  study  included: 

1.3 .2.1  DLR  Co-ord  staff. 

1 .3 .2.2  DLR  Staff  on  seven  active  projects. 

1 .3 .2.3  ADM  (MAT)  Project  Management  staff  on  select  projects. 

1 .3 .2.4  Instructor  staff  at  the  Technical  Staff  School  in  Kingston. 

1.3 .2.5  Human  Factors  Scientists  at  D.C.I.E.M. 

1 .3.3  This  D.C.I.E.M.  study  recommended  a  number  of  changes  to  the  process  of  developing 

SORs  and  Performance  Specifications,  focusing  on  User  Centred  Design  principles  and  a 
standardized  SOR  template.  Commensurate  with  these  process  changes  were  a  series  of 
recommendations  related  to  requirements  management  software. 

1.4  Capability  Deficiencies 

1 .4. 1  Requirements  Officers  (ROs)  do  not  have  a  standardized  process  to  follow  in  the 
development  of  SORs. 

1 .4.2  It  is  very  difficult  for  a  Requirements  Officer  to  locate  and  obtain  a  number  of  reference 
sources  that  are  frequently  used  in  SOR  development.  Examples  of  these  references 
include: 
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1.4.2. 1 

1. 4.2.2 

1.4.2.3 

1. 4.2.4 

1. 4.2.5 

1. 4.2.6 

1. 4.2.7 

1.4.3 

1.4.4 

1.4.5 

1.4.6 

1.4.7 

1.4.8 

1.4.9 

1.4.10 


1.5 

1.5.1 

1.5.2 

1.6 

1.6.1 
1.6.1. 1 


Historical  SORs  for  similar  systems. 

Current  SORs  for  related  systems. 

Relevant  DND  research  reports  on  both  technology  and  operations. 

Relevant  Doctrine  impacting  the  system  of  interest. 

Future  Operational  Concepts  related  to  the  system  under  development. 

Design  standards  related  to  user  performance. 

Lessons  Learned  from  unit  operations. 

There  is  no  common  template  for  SORs  currently  followed  within  DLR. 

Once  developed,  it  is  very  difficult  to  track  the  rationale  for  requirements  in  an  SOR. 

It  is  very  difficult  to  track  how  requirements  have  been  merged  or  split  into  new  versions 
of  requirements  during  the  editing  process. 

Most  projects  do  not  allocate  the  resources  to  track  the  interdependencies  between 
requirements. 

Most  projects  do  not  track  which  requirements  have  been  validated  with  users. 

It  is  very  easy  to  edit  requirements  without  recording  the  rationale  for  editing,  which 
decreases  the  ability  to  track  the  sources  of  requirements. 

It  is  very  difficult  to  track  the  relationship  between  requirements  and  specifications. 

It  is  labour  intensive  to  calculate  a  “Best  Value”  bid  evaluation  score  using  multiple 
layers  of  requirement/spec  priority.  This  challenge  contributes  to  the  rationale  to  use 
“Lowest  Cost”  bid  evaluation  techniques.  The  Lowest  Cost  evaluation  results  in 
requirements  being  classified  as  “Essential”  or  “Desirable”  only,  which  is  a  major 
distraction  for  the  project  staff. 


Project  Limitations  and  Constraints 

The  D.C.I.E.M.  study  that  developed  this  draft  SOR  was  conducted  rapidly,  with  limited 
resources  which  did  not  allow  for  validation  of  the  SOR-Spec  Maker  requirements  with 
the  future  user  community.  These  future  users  should  be  consulted  prior  to  finalization  of 
this  SOR  and  development  of  the  system  specification  for  product  evaluation  purposes. 

The  focus  of  the  D.C.I.E.M.  study  was  on  DLR  operations  and  the  development  of  the 
SOR  for  Army  systems.  Limited  analysis  was  conducted  of  Project  Management  and 
Engineering  staff  tasks,  which  should  be  extended  prior  to  finalizing  this  SOR. 

Related  Projects 

Ongoing  projects  within  DND  that  SOR-Spec  Maker  MUST  be  compatible  with  include: 

The  Directorate  of  Force  Planning  and  Project  Co-ordination  (DFPPC)  studies  to 
update  CFP  125  and  produce  a  new  SOR  Template.  Once  finalized  this  Force  wide 
SOR  template  MUST  be  incorporated  as  the  SOR  template  within  the  SOR-Spec 
Maker  software. 
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1 .6.2  Ongoing  projects  within  DND  that  SOR-Spec  Maker  SHOULD  monitor  for  potential 
links  include: 

1 .6.2. 1  Soldiers  Day,  as  a  reference  source  for  field  task  information  and  equipment 
requirements. 

1 .6.2.2  HFE  Guide,  as  a  reference  source  for  human  factors  design  requirements  and  analysis 
processes  if  this  tool  is  converted  to  a  PC  format. 

1 .6.2.3  Army  Lessons  Learned  Centre  CD-ROM  development  efforts,  as  a  key  source  of  for 
future  system  requirements. 

2  MISSION,  ROLES,  AND  TASKS 

2.1  Mission 

2.1.1  The  mission  of  the  DLR  Requirements  Officer  is  to  translate  Army  needs  into  Systems 

and  Equipment  to  meet  those  needs.  This  typically  consists  of  three  primary  tasks: 

2. 1 . 1 . 1  Monitoring  of  Technological  Developments,  both  domestic  and  international. 

2. 1 . 1 .2  Definition  of  Operational  Requirements. 

2. 1 . 1 .3  Negotiation  for  Project  Resources. 

2. 1 .2  The  mission  of  the  Project  Management  and  Engineering  staff  within  ADM(Mat)  is  to 
translate  Operational  Requirements  into  achievable,  testable  performance  specifications. 

2.2  Roles  /  Scenarios 

2.2. 1  The  SOR-Spec  Maker  software  tool  provides  support  to  two  classes  of  user: 

2.2. 1 . 1  The  Requirements  Officer  (RO)  -  who  is  the  DLR  staff  member  responsible  for  the 
development  of  a  Statement  of  Operational  Requirements,  which  contains  the 
functional  statements  of  system  requirements  to  meet  user  needs. 

2.2. 1 .2  The  Engineer  —  who  is  responsible  for  the  development  of  the  Performance 
Specification,  which  contains  the  technical  engineering  specifications  used  in  the 
procurement  process. 

2.2.2  Three  project  scenarios  have  been  considered  in  the  development  of  the  requirements  for 
the  SOR-Spec  Maker  software  tool: 

2.2.2. 1  Projects  identified  by  operational  units  through  field  deficiency  reporting 
mechanisms. 

2.2.2.2  Projects  identified  by  Commanders  or  Other  DND  HQ  Staff  through  the  review  of 
industry  and  trade  literature. 

2.2.2.3  Projects  directed  by  the  political  process. 

2.3  Concept  of  Operations 

2.3.1  SOR-Spec  Maker  will  be  a  software  tool  that  will  provide  support  to  the  requirements 
and  specification  management  process  in  three  key  areas: 


Humansyj/em5  Incorporate 


Page  B3 


2.3. 1.1 

2.3. 1.2 

2.3. 1.3 

2.3.2 


2.3.3 


2.3.4 


2.4 


2.4.1 


2.4.1. 1 

2.4. 1.2 

2.4. 1.3 

2.4. 1.4 

2.4. 1.5 

2.4. 1.6 

2.4. 1.7 

2.4. 1.8 

2.4. 1.9 
2.4.2 

2.4.2. 1 

2.4.2.2 

2.4.2.3 
2.42.4 

2.4.2.5 

2.4.2.6 
2.42.7 
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Links  to  Supporting  Information  and  References  —  which  will  allow  the  user  to  access 
key  sources  of  information  used  in  the  development  of  requirements  or  specifications. 

A  Process  Wizard  -  which  will  provide  the  user  with  guidance  through  the  key  steps 
of  the  requirements  development  process. 

Requirements/Specification  Management  —  which  will  provide  the  user  with  the  tools 
necessary  to  enter,  edit,  and  track  the  status  of  project  requirements  and  specifications. 

The  SOR-Spec  Maker  software  tool  will  be  used  by  ROs  within  DLR  and  by  PM  to 
develop,  record,  edit,  and  track  operational  requirements  and  specifications  throughout 
the  life  cycle  of  a  system. 

There  will  be  two  users  per  project  (The  DLR  Requirements  Officer,  and  the  Engineer  on 
the  Project  Management  Team),  and  subsequently  at  least  two  instances  of  SOR-Spec 
maker  per  project.  These  users  will  most  often  be  geographically  separated,  working  in 
separate  buildings  or  separate  floors  of  the  same  building. 

The  software  will  be  networked  such  that  the  both  user  can  view  the  current  version  of 
both  the  SOR  and  Performance  Specification,  however,  passwords  will  permit  only  DLR 
staff  to  edit  requirements  and  only  ADM(Mat)  staff  to  edit  specifications. 

Key  Tasks 

The  general  work  flow  with  the  SOR-Spec  Maker  software  will  involve  the  DLR 
Requirements  Officer  using  the  tool  to  conduct  the  following  key  tasks: 

Determine  the  key  steps  in  the  SOR  development  process  and  track  progress. 

Search  for  reference  sources  for  requirement  development. 

Enter  and  Edit  requirements,  indicating  rationale. 

Merge  and  Split  requirements  as  necessary. 

Identify  and  track  interdependencies  between  requirements. 

Indicate  requirements  as  “validated”  with  users. 

Number  requirements. 

Prioritize  requirements. 

Print  requirement  reports. 

The  general  work  flow  with  the  SOR-Spec  Maker  software  will  involve  the  Engineering 
staff  on  the  Project  Management  Team  using  the  tool  to  conduct  the  following  key  tasks: 

Search  for  reference  sources  for  specification  development. 

Enter  and  Edit  specifications,  indicating  rationale. 

Merge  and  Split  specifications  as  necessary. 

Identify  and  track  the  link  between  specifications  and  their  source  requirements. 
Identify  and  track  interdependencies  between  specifications. 

Indicate  specification  test  results. 

Number  specifications. 


Wummsystems  Incorporated 


Draft  for  DND  Review 

2A.2.8  Prioritize  specifications  based  on  requirement  priorities. 
2A.2.9  Print  specification  reports. 


2.5  Concept  of  Support 

2.5.1  SOR-Spec  Maker  training  will  initially  be  provided  through  informal  courses  taught  to 
active  DLR  staff. 

2.5.2  The  materials  developed  for  initial  DLR  training  will  be  passed  to  the  Technical  Staff 
School  in  Kingston  for  the  training  of  future  DLR  Requirements  Officers. 

2.5.3  Network  support  will  be  provided  by  local  system  administration  personnel  in  DND 
facilities. 

2.5.4  SOR-Spec  Maker  technical  support  will  be  provided  by  the  developer  of  the  software 
selected  to  meet  this  requirement. 


3  OPERATIONAL  ENVIRONMENT 

3.1  General 

3.1.1  SOR-Spec  Maker  will  be  used  on  desktop  Personal  Computers  (PCs)  in  a  networked 
environment. 

3.1.2  The  software  will  be  used  at  desks  under  typical  office  environmental  conditions. 

3.2  Threat 

3.2. 1  N/A  —  office  information  system. 

4  OPERATIONAL  REQUIREMENTS 

4.1  General 

4.1.1  SOR-Spec  Maker  should  provide  a  networked,  integrated,  software  environment  that 
consolidates  system  requirements,  specifications,  and  their  rationale. 

4. 1 .2  SOR-Spec  Maker  must  be  accessible  by  both  DLR  and  ADM(Mat)  staff  working  on  a 
project  from  their  PC  in  their  primary  office  area. 

4. 1 .3  SOR-Spec  Maker  must  provide  login  and  password  protection  for  each  DLR  and 
ADM(Mat)  user  with  different  privileges  for  each.  Key  privileges  include  restrictions 
whereby  only  the  authorized  DLR  officer  can  edit  requirements  and  only  the  authorized 
ADM(Mat)  officer  can  edit  specifications. 

4. 1 .4  SOR-Spec  Maker  must  provide  a  template  to  identify  all  key  project  support  personnel, 
with  contact  information  for  each,  and  should  provide  a  direct  e-mail  link  to  each. 

4. 1 .5  SOR-Spec  Maker  must  allow  users  to  enter  and  edit  data  in  either  English  or  French. 
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4.2  Design  and  Concept  Guidance 

4.2. 1  It  is  expected  that  SOR-Spec  Maker  is  a  Microsoft  Windows  based  product,  most  likely 
procured  as  Commercial  Off  the  Shelf  (COTS)  software. 

4.2.2  These  requirements  may  be  met  by  one  product,  or  by  up  to  three  different  products 
consisting  of: 

4.2.2. 1  A  Microsoft  Windows  based  Requirements  Management  tool. 

4 .2.2.2  An  Information  Source  product,  possibly  Intranet  based. 

4.2.2.3  An  SOR  Wizard  product,  possibly  Intranet  based. 

4.3  Total  System  Requirements 


4.3 . 1  Performance  Capability  -  Information  Links 

4.3 . 1 . 1  SOR-Spec  Maker  must  provide  the  user  with  a  means  to  directly  access  CD-ROMs 
and  Intranet  sites  within  DND  that  are  used  as  reference  materials  for  SOR 
development. 

4.3 . 1 .2  Links  to  CD-ROMS  should  be  common  links  whereby  a  central  program  storage 
device  is  used  for  many  users  to  access. 

4.3 . 1 .3  Information  links  must  be  updateable  over  the  network  by  one  system  administrator 
for  all  users. 


4.3. 1.4 

4.3. 1.5 


4.3. 1.6 

4.3. 1.6.1 

4.3. 1.6.2 

4.3. 1.6.3 

4.3. 1.6.4 

4.3. 1.6.5 

4.3. 1.6. 6 

4.3. 1.6.7 

4.3. 1.6.8 

4.3. 1.6.9 

4.3.1.6.10 


Information  links  should  be  grouped  as  Force  Wide,  Element  (Army,  Navy,  Air, 
Support),  and  Army  (Infantry,  Armoured,  etc..)  specific. 

SOR-Spec  Maker  should  contain  a  Missions/Scenario  section  that  provides  a  link  to  a 
summary  of  the  Land  Force  scenarios  that  system  must  support.  The  software  should 
allow  this  scenario  text  to  be  placed  in  the  Mission/Scenario  section  of  the  SOR  or  in 
an  Annex  depending  on  how  much  additional  data  the  Requirements  Officer  has  to 
incorporate  with  it. 

Information  links  should  be  provided  to: 

Electronic  Battle  Box  (CD-ROM  from  Directorate  of  Army  Doctrine) 

Soldiers  Day  (Multi-media  task/equipment  database  for  Mounted  and 
Dismounted  Infantry) 

SOR/Spec  Library  (consisting  of  the  most  recent  versions  of  SOR’s  and  Specs 
from  all  Force  Elements). 

DND  Branches,  Schools,  and  Unit  Intranet  Sites. 

Defence  Research  Establishments  (DREs)  including  links  to  personnel  by 
research  interests,  recent  reports,  and  library  holdings. 

DRDIM  literature  search  services. 

Industrial  Search  Engines  (eg:  NTIS) 

Lessons  Learned  Centre  Databases 

Recent  Deficiency  Databases  from  Sources  such  as  UCRs  or  the  Army  Combat 
Clothing  and  Equipment  Survey  System  (ACCESS). 

Listings  of  DND  Libraries  for  Military  and  Industrial  Standards  and  Design 
Guidelines. 
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4.3.1 .7  SOR-Spec  Maker  must  allow  users  to  cut  and  paste  from  open  documents  viewed 
through  the  Intranet  or  Windows  based  applications. 

4.3.1 .8  SOR-Spec  Maker  should  include  links  to  Intranet  sites  as  a  component  of  a  document 
reference  in  an  electronic  SOR. 

4.3.2  Performance  Capability  -  SOR  Wizard 

4.3.2. 1  SOR-Spec  Maker  must  provide  the  user  with  an  SOR  Wizard  that  indicates  the  key 
milestones  and  process  expected  in  the  development  of  an  SOR. 

4.3. 2.2  The  SOR  Wizard  must  be  based  on  a  documented  process  for  SOR  development 
within  DLR  (to  be  developed). 

4.3. 2.3  The  SOR  Wizard  must  allow  the  user  to  initiate  a  project,  and  define  the  anticipated 
schedule  to  meet  each  of  the  major  project  milestones. 

4.3. 2.4  The  SOR  Wizard  must  provide  the  user  with  a  mechanism  to  indicate  when  each 
major  milestone  has  be  completed.  This  feature  must  include  the  ability  to  enter  a  free 
text  description  of  the  activities  completed  towards  the  milestone. 

4.3. 2.5  The  SOR  Wizard  must  generate  work  planning  reports  including: 

4.3.2.5.1  A  Status  Report  indicating  all  milestones,  date  of  planned  completion,  and  data 
of  actual  completion. 

4.3.2.5.2  “To  Do”  lists  summarizing  uncompleted  task  and  date  planned  for  completion. 

4.3. 2.6  SOR  Wizard,  and  any  associated  help  system,  should  provide  links  to  DND  resources 
related  to  tasks  that  must  be  completed  or  SOR  sections  that  must  be  completed  (eg: 
links  to  DCIEM  for  human  factors  issues). 

4.3.3  Performance  Capability  -  SOR  Development 

4.3 .3 . 1  SOR-Spec  Maker  must  allow  the  DLR  Requirements  Officer  to: 

4.3 .3 . 1 . 1  Very  easily  enter  a  new  requirement. 

4.3 .3 . 1 .2  Copy  and  Paste  a  new  requirement  from  other  Windows  based  software. 

4.3 .3 . 1 .3  Edit  a  requirement  already  entered  into  the  software. 

4.3 .3 .2  A  Requirement  in  SOR-Spec  Maker  must  contain  at  least  the  following  information: 

4.3 .3 .2. 1  A  Number. 

4.3 .3 .2.2  A  Title. 

4.3. 3. 2.3  A  Priority  (numerical  value). 

4.3 .3 .2.4  The  Full  Requirement  Description. 

4.3.3.2.5  The  Source  of  a  Requirement. 

4.3.3.2.6  The  Rationale  for  a  Requirement  or  it’s  Edit. 

4.3. 3. 2.7  A  comments  field. 

4.3 .3 .3  SOR-Spec  Maker  must  allow  the  user  to  delete  a  requirement  from  the  active 
requirements  list,  but  must  maintain  it  (any  rationale  entered  for  deletion)  in  the 
history  of  the  project. 

4.3.3 .4  SOR-Spec  Maker  must  allow  the  user  to  split  a  requirement  into  multiple 
requirements. 
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433.5 

4 .3.3.6 

4. 3.3.7 

4.3.3.8 

4.3.3.9 

4.3.3.10 

4.3.3.11 

4.3.3.11.1 

4.3.3.11.2 

4.3.3.11.3 

4.3.3.12 

4.3.3.13 

4.3.3.14 

4.3.3.15 

4.3.3.15.1 

4.3.3.15.2 

4.3.3.15.3 


SOR-Spec  Maker  must  allow  the  user  to  merge  multiple  requirements  into  one 
requirement. 

SOR-Spec  Maker  must  number  and  maintain  the  numbering  of  requirements  through 
editing,  deleting,  splitting,  and  merging.  This  numbering  must  follow  the  approved 
DND  template. 

SOR-Spec  Maker  must  provide  context  sensitive  help  to  provide  direction  on  the 
expected  contents  of  each  section  of  the  SOR  being  completed. 

SOR-Spec  Maker  should  provide  direction  to  the  user  on  resources  within  DND 
(DREs,  Schools,  Libraries,  etc..)  that  can  provide  assistance  on  completing  each 
section. 

SOR-Spec  Maker  must  allow  the  user  to  define  interdependencies  between 
requirements  in  a  hierarchical  fashion  such  that  requirements  are  nested  within 
“parent”  and  “children”  relationships. 

SOR-Spec  Maker  must  allow  the  user  to  indicate  whether  a  requirement  in  its  current 
form  has  been  validated  by  users  since  it’s  last  edit. 

SOR-Spec  Maker  should  indicate  the  method  used  to  validate  the  latest  version  of 
each  requirement,  including  at  least  the  following  methods: 

Document  Review 
User  Focus  Group 
Product  Trial 

SOR-Spec  Maker  must  allow  the  user  to  ‘freeze’  an  SOR  whereby  the  current  list  of 
active  requirements  are  consolidated  into  an  SOR  document  with  a  revision  number, 
suitable  for  distribution  and  review. 

SOR-Spec  Maker  must  provide  a  means  for  the  user  to  submit  each  ‘frozen’  version 
of  an  SOR  or  a  Specification  to  an  SOR  Library,  where  the  most  recent  version 
overwrites  the  older  version  if  one  exists. 

The  SOR/Spec  Library  must  be  a  searchable  database,  using  the  SOR-Spec  Maker 
software,  allowing  the  user  to  open  a  located  SOR  and  copy  requirements  or 
specifications  from  the  located  document. 

SOR-Spec  Maker  must  output  active  requirements  in  report  format.  Modifiable 
report  templates  must  include: 

SOR  Report,  in  the  current  standard  DND  format. 

SOR  Report,  with  requirement  rationale  in  tabular  format  to  support  document 
review. 

A  Requirement  Interdependency  Report  that  illustrates  the  hierarchical 
relationship  between  requirements  in  an  understandable  tabular  or  graphical 
format. 


4.3 .4  Performance  Capability  -  Specification  Development 

4.3 .4. 1  SOR-Spec  Maker  must  allow  the  DLR  Specifications  Officer  to: 

4.3.4. 1 . 1  Enter  a  new  specification. 

4.3.4. 1 .2  Copy  and  Paste  a  new  specification  from  other  Windows  based  software. 

4.3 .4. 1 .3  Edit  a  specification  already  entered  into  the  software. 
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A  Specification  in  SOR-Spec  Maker  must  contain  at  least  the  following  information: 
A  Number. 

A  Title. 

A  Priority  (linked  to  the  priority  of  the  requirement  upon  which  it  was  based). 
The  Full  Specification  Description. 

The  Source  of  a  Specification. 

The  Rationale  for  a  Specification  or  it’s  Edit. 

A  comments  field. 

SOR-Spec  Maker  must  allow  the  user  to  delete  a  specification  from  the  active 
specifications  list,  but  must  maintain  it  (any  rationale  entered  for  deletion)  in  the 
history  of  the  project. 

SOR-Spec  Maker  must  allow  the  user  to  link  a  specification  to  the  requirement  in  the 
SOR  upon  which  it  was  based.  This  link  must  be  incorporated  into  interdependency 
reports. 

SOR-Spec  Maker  must  allow  the  user  to  split  a  specification  into  multiple 
specifications. 

SOR-Spec  Maker  must  allow  the  user  to  merge  multiple  specifications  into  one 
specification. 

SOR-Spec  Maker  must  number  and  maintain  the  numbering  of  specifications  through 
editing,  deleting,  splitting,  and  merging. 

SOR-Spec  Maker  must  allow  the  user  to  define  interdependencies  between 
specifications  in  a  hierarchical  fashion  such  that  specifications  are  nested  within 
“parent”  and  “children”  relationships. 

SOR-Spec  Maker  must  allow  the  user  to  indicate  whether  a  specification  in  its  current 
form  has  been  tested  since  it’s  last  edit. 

SOR-Spec  Maker  should  indicate  the  method  used  to  test  the  latest  version  of  each 
specification. 

SOR-Spec  Maker  must  allow  the  user  to  ‘freeze’  a  SPEC  whereby  the  current  list  of 
active  specifications  are  consolidated  into  an  SPEC  document  with  a  revision  number, 
suitable  for  distribution  and  review. 

SOR-Spec  Maker  must  provide  a  means  for  the  user  to  submit  each  ‘frozen’  version 
of  an  SOR  or  a  Specification  to  a  SPEC  Library,  where  the  most  recent  version 
overwrites  the  older  version  if  one  exists. 

The  SOR/Spec  Library  must  be  a  searchable  database,  using  the  SOR-Spec  Maker 
software,  allowing  the  user  to  open  a  located  SPEC  and  copy  specifications  or 
specifications  from  the  located  document. 

SOR-Spec  Maker  must  output  active  specifications  in  report  format.  Modifiable 
report  templates  must  include: 

SPEC  Report,  in  the  current  standard  DND  format. 

A  Specification  Interdependency  Report  that  illustrates  the  hierarchical 
relationship  between  requirements  in  an  understandable  tabular  or  graphical 
format. 
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4.3.5  Human  Factors  Requirements 

4.3.5. 1  Soldier  /  Crew  Task  Performance 

4.3 .5 . 1 . 1  SOR-Spec  Maker  must  permit  a  trained  user  to  enter  the  details  of  a  new 
requirement  in  one  minute  or  less.  This  time  of  entry  must  be  achievable  at  the 
initiation  of  a  project  and  also  when  there  are  over  5000  entries  in  the  document. 

4.3 .5 . 1 .2  SOR-Spec  Maker  should  alert  the  user  that  duplicate  requirements  or 
specifications  are  active  in  the  project. 

4.3. 5.2  Soldier-Machine  Interface  /  Crew  Station 

4.3. 5. 2. 1  SOR-Spec  Maker  must  be  a  compatible  with  the  operating  system  used  by  DLR 
staff  on  their  networked  desktop  computers. 

4.3 .5.2.2  SOR-Spec  Maker  should  adhere  to  the  interface  style  guides  for  the  operating 
system  used  on  the  DLR  staff  desktops  (eg:  Windows  ’95  Style  Guide). 

4.3. 5. 3  Health  Hazards  and  System  Safety 

4.3. 5.3.1  N/A  -  no  concerns  with  environmental  or  systems  safety  from  software  design, 
software  not  used  for  extended  periods  therefore  no  concerns  with  human  error  or 
excessive  mental  workload. 

4.3.5.4  User  Acceptance 

4.3. 5.4. 1  The  SOR-Spec  Maker  candidate  product  must  be  reviewed  by  representative 
future  users  through  part-task  user  trials. 

4.3.5.4.2  The  SOR-Spec  Maker  product  reviewed  must  be  judged  by  a  majority  of  users  to 
be  useful  and  easy  to  use. 

4.3.6  Quantity 

4.3.6. 1  The  initial  purchase  of  SOR-Spec  Maker  software  must  be  sufficient  to  support  both 
DLR  and  ADM(Mat)  staff  for  the  projects  it  will  be  used  in  support  of. 

4.3. 6.2  The  initial  purchase  of  SOR-Spec  Maker  software  should  include  110  units  to  support 
the  staff  complement  within  the  current  active  project  set  and  instructional  needs  at 
the  Kingston  Technical  Staff  School. 

4.3.7  Quality 

4.3.7. 1  SOR-Spec  Maker  must  be  a  completed,  final,  polished  software  product  with  full 
documentation  and  commercial  support.  It  must  not  be  a  product  under  development. 

4.3.8  Location 

4.3.8. 1  SOR-Spec  Maker  should  be  installed  with: 

4.3.8. 1.1  52  DLR  users  at  their  offices. 

4. 3. 8. 1.2  52  ADM  (Mat)  users  at  their  offices. 

4.3.8. 1 .3  6  workstations  at  the  Kingston  Technical  Staff  School. 
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5  TOTAL  SUPPORT  REQUIREMENT? 

5.1  Support  Requirements 

5.1.1  SOR-Spec  Maker  must  be  supported  on  the  network  by  existing  DND  system 
administration  staff. 

5.1.2  SOR-Spec  Maker  products  must  come  with  technical  support  from  the  developer. 

5.2  Personnel  and  Training 

5.2. 1  SOR-Spec  Maker  must  be  staffed  by  the  Requirements  Officer  (DLR)  and  Project 
Management  Engineering  Officer  (ADM(Mat))  for  each  active  project. 

5.2.2  Therefore,  SOR-Spec  Maker  must  be  operable  by  a  wide  range  of  users.  The  “worst” 
case  users  (from  a  design  perspective)  include  those  with  limited  knowledge  of  the 
procurement  process,  limited  knowledge  of  SOR  content  and  structure,  and  little 
computer  knowledge  or  typing  skills.  The  “best”  case  users  will  have  significant  SOR 
and  acquisition  experience  and  knowledge,  and  by  extremely  computer  literate.  The 
SOR-Spec  Maker  software  must  provide  the  ease  of  use  necessary  for  novice  users  to 
complete  an  SOR  effectively  and  easily,  while  providing  short  cuts  and  more  advanced 
data  manipulation  techniques  to  be  perceived  as  easy  to  use  and  useful  by  the  more 
sophisticated  users. 

5.2.3  Initial  deployment  of  the  software  tool  must  be  accompanied  by  information  training  at 
DLR. 

5.2.4  Computer  Based  Training  should  be  considered  for  ongoing  and  refresher  training  within 
NDHQ. 

5.2.5  Subsequent  training  should  be  incorporated  into  the  Technical  Staff  School  course  in 
Kingston. 

5.2.6  All  SOR-Spec  Maker  training  should  be  task  based  within  the  context  of  realistic 
procurement  scenarios. 

6  SCHEDULING  REQUIREMENTS 

6.1  Critical  Milestones 

6.1.1  Proposed  milestones  for  the  project  include: 

6. 1 . 1 . 1  SOR-Spec  Maker  Concept  Presentation  -  April  1998; 

6. 1 . 1 .2  SOR-Spec  Maker  Prototype  Use  on  Example  Project  -  Nov  1 998; 

6.1. 1.3  SOR-Spec  Maker  Software  Specification  -  Feb  1999; 

6. 1.1. 4  SOR-Spec  Maker  Software  Procurement  -  Mid  1999. 

6.2  System  Service  Life  Expectancy 
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6.2.1  It  is  expected  that  SOR-Spec  Maker  will  be  in  Service  mid  1999,  and  that  it  will  be 
effective  to  2010+  assuming  ongoing  manufacturer  support  and  upgrades  to  maintain 
compatibility  with  Operating  Systems  and  no  revolutionary  changes  to  DND  Staffing  or 
procurement  procedures. 

7  REQUIREMENTS  TABLE 

To  Be  Completed  in  Next  Version. 
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